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Kernel  Facilities  Definition 


Abstract:  Defines  the  conceptual  design  of  the  Kernel  by  specifying: 

•  The  underlying  models,  assumptions,  and  restrictions  that  govern  the 
design  and  implementation  of  the  Kernel;  and 

•  The  behavioral  and  performance  requirements  to  which  the  Kernel  is 
built. 

This  document  is  the  requirements  and  top  level  design  document  for  the 
Kernel. 


Preface 

Purpose  of  This  Document 

This  document  defines  the  proposed  functionality  of  a  Distributed  Ada  Real-Time  Kernel 
(hereafter  called  the  Kernel).  The  Kernel  Is  being  developed  as  one  artifact  of  the  Distributed  Ada 
Real-Time  Kernel  Project  (hereafter  called  the  project).  The  goal  of  the  Kernel  is  to  support 
effectively  the  execution  of  distributed  Ada  applications  in  an  embedded  computer  environment. 
As  discussed  in  [Firth  87],  the  Kernel  will  provide  users  with  support  for  language  functionality 
(i.e.,  the  ability  to  execute  Ada  programs  in  a  distributed,  real-time  environment);  it  will  not  provide 
support  for  language  features  (i.e.,  Ada  tasking  primitives).  As  a  result,  the  Kernel  specification 
will  place  certain  requirements  (restrictions  and  conventions)  on  the  Ada  application  programs 
that  use  the  Kernel.  These  will  become  apparent  to  the  reader  as  the  definition  of  the  Kernel  is 
expounded. 

Structure  of  This  Document 

This  document  is  divided  into  three  major  parts: 

1.  Kernel  Background:  describes  the  models  on  which  the  Kernel  is  based  and 
outlines  the  scope  of  its  activities. 

2.  Requirements:  describes  the  functionality  required  of  the  Kernel  and  the 
performance  expected. 

3.  Kernel  Interface:  describes  the  mechanisms  and  primitive  capabilities  the  Kernel 
provides  to  implement  the  requirements. 

In  addition  to  the  major  parts,  there  are  three  appendices: 

•  Appendix  A:  defines  the  terms  used  throughout  the  document. 

•  Appendix  B:  maps  requirements  onto  the  appropriate  Kernel  primitives. 

•  Appendix  C:  the  inverse  of  Appendix  B;  maps  the  primitives  onto  the  appropriate 
requirements. 
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I.  Kernel  Background 


This  part  of  the  Kernel  definition  provides  the  needed  background  material  to  understand  the 
remainder  of  the  document.  In  particular,  it  provides: 

1 .  The  rationale  for  the  Kernel  and  the  goals  to  be  achieved  by  it  (Chapter  1 ). 

2.  The  definitions  used  in  the  document  (Chapter  2). 

3.  An  overview  of  the  Kernel’s  functionality  (Chapter  3). 

4.  A  complete  discussion  of  the  assumptions,  models,  and  restrictions  on  which  the 
Kernel  requirements  and  primitives  are  based  (Chapter  4). 
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1.  Rationale 


Ada  is  now  being  mandated  for  a  large  number  of  DoD  development  projects  as  the  sole 
programming  language  to  be  used  for  developing  software.  Many  of  these  projects  are  trying  to 
build  distributed  real-time  systems.  Many  project  managers  and  contractors  are  anxious  to 
support  this  effort,  to  reap  the  advantages  of  Ada,  and  to  use  the  newer  techniques  of  software 
engineering  that  Ada  can  support.  This  transition,  however,  has  not  always  been  smooth;  some 
serious  problems  have  been  encountered. 


1.1.  Ada  Runtime  Environment 

One  of  the  most  persistent,  and  worrying,  problems  is  the  suitability  of  the  Ada  runtime  system, 
most  notably  the  tasking  features,  and  especially  on  distributed  systems.  There  are  issues 
concerning  functionality  (amply  documented  by  ARTEWG),  customization,  tool  support 
(especially  target  debuggers  and  performance  monitors),  issues  of  inter-process  communication 
and  code  distribution;  and,  perhaps  most  intractable,  issues  of  execution-time  efficiency. 

One  way  of  approaching  this  problem  is  to  press  for  better,  "more  mature"  Ada  implementations; 
more  optimization;  user-tailorable  runtime  systems;  special-purpose  hardware.  This  is  a  valid 
route,  but  one  that  will  take  time,  money,  and  experience,  and  many  of  the  solutions  will  be 
compiler-dependent,  machine-dependent,  or  application-dependent.  Many  developers  are  still 
unsure  even  how  to  use  the  new  language  features  of  Ada;  and  at  least  one  cycle  of  application 
use,  performance  measurement,  and  methodology  review  will  be  needed  before  we  can  be  sure 
what  parts  of  the  Ada  language  and  runtime  are  indeed  critical. 

This  project  looks  at  another  route  to  a  possible  solution.  It  should  be  a  quicker  and  cheaper 
route,  and  hence  a  feasible  short-term  alternative. 


1.2.  Applications  and  Systems  Code 

In  conventional  programming,  application  code  (which  is  what  has  to  be  written  to  meet  the  user 
requirements)  is  distinguished  from  system  code  (which  is  obtained  with  the  target  machine,  and 
which  is  intended  to  support  applications  generally).  With  Ada  and  embedded  systems,  these 
distinctions  are  not  so  clear  cut.  First,  it  has  been  traditional,  when  developing  real-time  systems 
in  other  programming  languages,  for  the  application  programmer  to  write  specific  code  down  to  a 
far  lower  level,  including  special  device  drivers,  special  message  or  signaling  systems,  and  even 
a  custom  executive.  There  is  far  less  general-purpose  system  code.  Secondly,  the  Ada  language 
complicates  the  distinction  between  application  and  system  code.  In  older  languages,  almost  all 
system  functions  were  invoked  through  a  simple  and  well-understood  interface  — the  system  call 
—  expressed  as  a  normal  subroutine  call.  In  Ada,  however,  many  traditionally  system-level 
functions  are  explicit  in  the  language  itself,  or  implied  by  language  constructs;  for  example, 
tasking,  task  communication,  interrupt  acquisition,  and  error  handling.  In  fact,  the  work  is  really 
done  by  the  old  familiar  system  code,  now  disguised  as  the  Ada  runtime. 
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1.3.  Abstractions  and  their  Breakdown 


If  the  user  is  satisfied  with  the  Ada  level  of  abstraction  —  with  its  view  of  what  tasks  are,  what 
time  is,  and  so  on  —  then  the  Ada  view  is  a  simplification:  the  application  code  in  fact  performs 
system  calls,  but  the  compiler  inserts  them  automatically  as  part  of  the  implementation  of 
language  constructs.  One  very  successful  example  of  how  useful  this  can  be  is  the  Monitor 
construct.  The  user  declares  a  procedure,  or  group  of  procedures,  to  be  a  Monitor;  on  Monitor 
invocations,  the  compiler  automatically  inserts  the  system  calls  that  enforce  mutual  exclusion;  the 
abstraction  captures  exactly  what  the  user  wants,  and  the  implementation  is  done  without  fuss. 

Unfortunately,  many  users  are  dissatisfied  with  the  Ada  abstraction,  and  seek  either  finer  control 
or  access  to  lower-level  concepts,  such  as  semaphores,  send/wait  or  suspend/resume  primitives, 
and  bounded  time  delays.  Under  the  above  circumstances,  the  extra  language  features,  and  the 
hidden  system  calls  they  generate,  are  an  active  hindrance  to  the  application  programmer,  and 
an  obstruction  to  the  work  of  implementation. 

For  example,  the  programmer  may  need  a  strong  delay  primitive  —  one  that  guarantees 
resumption  as  soon  as  possible  after  the  expiration  of  the  delay.  But  Ada  already  has  a  "delay" 
statement,  with  different  semantics.  When  implementing  a  different  delay  primitive,  the  user  risks 
damaging  the  Ada  runtime  behavior,  which  believes  it  has  sole  control  of  the  Ada  tasks,  and  does 
not  expect  an  extra  routine  that  performs  suspensions  and  resumptions.  To  Implement  the  new 
delay  robustly,  the  user  has  to  interface  with  the  internals  of  the  Ada  runtime,  which  may  be  very 
hard  to  do  and  will  surely  be  hard  to  maintain.  Moreover,  the  Ada  delay  statement  composes 
naturally  into  timed  entry  calls  and  timed  select  statements.  If  the  user  wishes  to  do  these  things 
with  the  new  delay  statement,  a  substantial  part  of  the  Ada  semantics  must  be  rebuilt,  and  a 
substantial  part  of  the  runtime  must  be  modified. 

All  this,  of  course,  is  a  distraction  from  the  real  work  —  the  work  of  Implementing  the  application. 
One  of  the  main  motivators  of  this  project  is  the  observation  that  many  contractors  using  Ada  are 
spending  most  of  their  time  worrying  about  the  Ada  system  level  and  far  too  little  time  solving  the 
application  problems,  some  of  which  are  not  easy. 

In  sum,  it  can  be  harder  to  build  applications  using  Ada  language  features  than  it  would  be  to 
implement  the  required  functionality  without  them.  But  it  is  also  undesirable  for  every  application 
to  reinvent  specific  incarnations  of  real-time  functional  abstractions. 


1.4.  Distributed  Applications 

A  further  and  equally  difficult  problem  is  the  Issue  of  executing  applications  on  a  distributed  target 
configuration.  Good  software  development  methods  teach  us  to  decompose  large  applications 
into  functional  units  communicating  through  well-defined  interfaces.  The  physical  allocation  of 
such  units  to  individual  processors  in  the  target  environment  can  be  done  In  many  ways,  without 
impairing  their  functionality.  Good  design  therefore  requires  that  the  specification  of  these 
functional  units  and  interfaces  be  independent,  as  far  as  possible,  of  their  physical  distribution. 
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In  a  real-time  system,  this  implies  that  the  mechanisms  by  which  units  interact  —  to  synchronize, 
communicate  with,  schedule  one  another,  or  alert  one  another  —  should  be  uniform,  regardless 
of  whether  the  units  are  situated  on  the  same  processor  or  at  some  distance  across  a  distributed 
network.  If  the  implementation  language  is  Ada,  this  leads  to  a  requirement  for  distributed  Ada. 

Unfortunately,  nearly  all  current  commercially-available  Ada  implementations  do  not  meet  this 
requirement.  They  implement  the  real-time  mechanisms  of  the  language  only  on  individual  or 
isolated  processors,  and  provide  no  help  with  communication  between  processors,  and  hence 
between  units  on  different  machines.  This  situation  leads  to  systems  where  Ada  tasks 
communicate  by  different  mechanisms,  with  different  style,  semantics  and  implementations, 
merely  because  the  Ada  tasks  are  local  in  one  case,  and  remote  in  the  other.  It  also  requires  the 
physical  distribution  of  tasks  to  be  unalterably  fixed  before  any  task  is  implemented,  and,  In  some 
cases,  before  Interface  design  is  complete. 

Overall,  there  is  a  substantial  loss  of  application  clarity,  maintainability,  reconfigurability,  and 
conceptual  economy. 

1.5.  Real-Time  Requirements 

This  brings  us  to  the  crux  of  this  project’s  rationale.  Users  —  people  who  have  to  write 
application  code  —  do  not  want  language  features:  they  want  language  functionality.  In  Ada, 
much  of  the  real-time  functionality  Is  captured  in  the  form  of  special  features.  This  may  well  be 
(the)  correct  solution  In  the  long  term,  since  by  making  real-time  operations  explicit  in  the 
language,  the  compiler  is  permitted  to  apply  its  intelligence  to  their  optimization  and  verification. 
But  In  the  short  term,  it  Is  palpably  not  working:  the  users  either  cannot  use,  or  do  not  know  how 
to  use,  the  given  features  to  achieve  the  required  functionality;  the  implementors  of  the  language 
do  not  know  how  to  satisfy  the  variety  of  needs  of  real-time  applications;  the  vendors  are 
unwilling,  or  unable,  to  extensively  customize  validated  implementations;  and  commercial  support 
for  distributed  targets  is  rare,  even  as  the  need  for  such  support  is  becoming  endemic  among 
application  developers. 

Accordingly,  it  is  opportune  to  revert  to  the  former  method  of  providing  functionality:  by  specific 
system  software  implemented  as  a  set  of  library  routines  and  invoked  explicitly  by  the  user.  This 
project  will  do  precisely  that. 


1.6.  Purpose  and  Intended  Audience 

The  main  purpose  of  the  Kernel  is  to  demonstrate  that  it  is  possible  to  develop  application  code 
entirely  in  Ada  that  will  have  acceptable  quality  and  real-time  performance.  This  purpose  will  be 
achieved  by  providing  a  prototype  artifact  that  implements  the  necessary  functionality  required  by 
real-time  applications,  but  in  a  manner  that  avoids  or  mitigates  the  efficiency  and  maturity 
problems  found  in  current  Ada  runtime  implementations. 

This  prototype  embodies  a  tool-kit  approach  to  real-time  systems,  one  that  allows  the  user  to 
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build  application-specific  real-time  abstractions.  This  prototype  is  not  intended  to  solve  all  the 
problems  of  embedded,  real-time  systems,  nor  is  it  the  only  solution  to  these  problems.  However, 
it  is  intended  to  be  a  solution  where  efficiency  and  speed  are  the  primary  drivers  and,  where 
warranted,  functionality  is  limited  to  satisfy  these  drivers. 

Given  this,  the  purpose  of  such  a  prototype  is: 

1 .  To  encourage  people  to  use  Ada  for  applications  code  by  mitigating  many  of  their 
problems. 

2.  To  allow  developers  to  concentrate  on  the  application-specific  areas  of  their 
problem  by  providing  them  with  a  set  of  working  system  primitives  that  are  more 
familiar,  that  can  be  invoked  in  a  more  customary  way,  and  that  can  be  built  upon. 

3.  To  offer  a  usable  support  base,  of  known  functionality  and  quality,  for  real-time  Ada 
applications. 

This  document  does  not  address  those  software  engineers  who  find  their  system  constraints  met 
within  the  Ada  tasking  paradigm.  The  general  audience  is  anyone,  within  the  defense  community 
or  without,  who  is  anxious  to  use  Ada  but  is  troubled  by  currently  perceived  problems.  This 
especially  includes  software  engineers  operating  in  a  distributed,  real-time  environment. 
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2.  Definitions 


This  document  begins  with  two  key  definitions  (see  Appendix  A  for  a  complete  set  of  definitions): 

•  Ada  task:  An  Ada  language  construct  that  represents  an  object  of  concurrent 
execution  managed  by  the  Ada  run-time  environment  (RTE)  supplied  as  part  of  a 
compiler  (under  the  rules  specified  in  the  Ada  Language  Reference  Manual  (LRM), 
see  [alrm  83]). 

•  Kernel  process:  An  object  of  concurrent  execution  managed  by  the  Kernel  outside 
the  knowledge  and  control  of  the  Ada  RTE. 

The  preceding  terminology  is  deliberately  different  from  that  of  Ada.  This  is  for  two  reasons: 

1 .  To  remind  the  reader  not  to  think  in  Ada  terms,  but  rather  in  the  terms  defined  by 
this  document. 

2.  To  avoid  the  Implication  that  the  Kemei  will  implement  any  specific  function  in  a  way 
that  resembles  an  existing  Ada  feature  with  that  function. 

This  document  will  focus  specifically  on  Kernel  processes,  not  on  Ada  tasks.  In  fact,  except  for 
“academic  interest"  or  comparison/contrastive  purposes,  the  term  “Ada  task”  will  not  appear  in 
this  document.  To  elaborate  on  this  view,  (keep  in  mind  that)  a  Kernel  process  is  a  schedulable 
unit  of  parallel  execution.  Thus,  at  any  one  instant,  any  one  processor  is  executing  the  code  of 
exactly  one  process  or,  alternatively,  is  executing  Kernel  code.  The  code  of  a  Kernel  process  is 
written  by  the  user  and  will  be  an  Ada  procedure.  What  distinguishes  a  procedure  from  a 
process,  or  for  that  matter  from  an  interrupt  handler,  is  the  execution  environment.  The  Kernel 
primitives  will  take  an  appropriate  Ada  procedure  and  construct  around  it  the  necessary  execution 
environment  to  create  a  Kernel  process.  1This  will  be  discussed  in  more  detail  later. 


'The  Ada  compiler,  in  contrast,  constructs  the  proper  environment  around  a  procedure  or  task. 
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3.  Kernel  Functional  Areas 


This  chapter  briefly  summarizes  the  areas  that  the  Kernel  will  and  will  not  address.  First,  the 

Kernel  will  not  address  the  following  areas: 

•  Multi-level  security:  This  is  beyond  the  scope  of  this  Project. 

•  Rollback/checkpoint  recovery:  The  Kernel  is  not  dealing  with  the  issues  of  fault 
tolerance:  however,  it  will  address  some  of  the  issues  of  fault  detection  and 
reporting. 

•  Memory/storage  management  and  garbage  collection:  In  general,  the  Kernel 
expects  all  processes  on  one  processor  to  execute  in  the  same  uniform  address 
space,  freely  sharing  global  data.  Also,  the  Kernel  will  not  manage  memory  for 
access  collections,  because  the  characteristics  of  many  embedded  systems  preclude 
an  implementation  assuming  any  kind  of  garbage  collection. 

•  Pre-elaboration:  Since  the  Kernel  is  not  dealing  with  Ada  tasking  (and  concomitant 
semantics),  this  is  not  needed. 

•  Fast-interrupt  pragma:  The  Kernel  is  excluding  this  pragma  because  it  is  specific  to 
Ada  task  entries  and  to  some  compilers.  The  Kernel  will  provide  equivalent 
functionality  via  Kernel  primitives. 

The  Kernel  will  address  the  following  areas: 

•  Processor  management 

•  Process  management 

•  Semaphore  management 

•  Schedule  management 

•  Communication  management 

•  Interrupt  management 

•  Time  management 

•  Alarm  management 

•  Tool  interface 

Each  of  these  items  will  be  discussed  in  more  detail  in  subsequent  chapters  in  this  document. 
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4.  Assumptions,  Models,  and  Restrictions 

Chapter  3  defined  broad,  general  categories  of  functionality.  To  refine  these,  this  chapter 
presents  a  set  of  models,  assumptions,  and  restrictions  on  which  the  Kernel  is  based. 


4.1.  Ada  Compiler  Assumptions 

Regarding  the  Ada  compiler  and  its  relationship  to  the  Kernel: 

1 .  No  additional  pragmata  will  be  implemented  or  existing  pragmata  modified. 

2.  If  possible,  the  Kernel  will  be  developed  using  an  Ada  compiler,  which  allows  the 
Ada  tasking  RTE  to  be  excluded  from  the  executable  image;  this  implies  that  no 
modifications  will  be  made  to  the  rest  of  the  Ada  RTE. 

3.  The  compiler  supplied  Ada  run-time  must  be  re-entrant. 

4.  Only  as  a  last  resort  will  the  Ada  compiler  and/or  RTE  be  modified  (to  force  the 
exclusion  of  the  tasking  support  library  from  the  executable  image),  and  no  changes 
will  be  made  that  would  invalidate  the  compiler. 

5.  The  Kernel  will  have  total  control  over  the  system  clock. 

The  selection  of  a  compiler  is  driven  by  the  above  needs  and  by  the  needs  of  the  model 
application  used  to  test  the  Kernel.  It  is  not  driven  by  any  needs  of  the  Kernel  itself.  Given  that 
no  modifications  will  be  made  the  RTE,  it  will  continue  to  provide  all  services  needed  by  the 
application  except  those  related  to  concurrency. 

4.2.  Process  Model 

The  Kernel  presents  to  the  user  the  abstraction  of  a  process,  that  is,  a  concurrent  thread  of 
execution  (as  defined  in  Chapter  2).  Elaborating  on  this  general  concept  yields  the  Kernel's 
general  process  model: 

1 .  Each  process  executes  a  unit  of  code,  developed  as  a  functional  unit. 

2.  For  each  processor,  the  software  engineer  performs  the  following  steps  (illustrated 
in  Figure  4-1): 

a.  Develop  the  process  code. 

b.  Develop  the  Main  Unit  for  the  processor;  the  function  of  the  Main  Unit  is 
explained  later. 

c.  Compile  the  code  of  the  processes  and  the  Main  Unit. 

d.  Link  the  Kernel,  Main  Unit,  and  processes  together  to  form  the  load  image 
for  that  processor. 

3.  The  load  image  begins  execution  at  the  initialization  point  of  the  Kernel,  which  in 
turn  invokes  the  Main  Unit. 

When  developing  a  process,  the  software  engineer  need  not  know  where  the  other  processes  will 
be  located  —  on  a  single  processor  or  across  multiple  processors.  The  Kernel-supplied 
communication  primitives  can  be  used  for  all  inter-process  communication,  local  or  remote,  with 
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p.  :  Process  #i  running  on  processor  q. 

Main  Unit:  The  Ada  Main  Unit  running  on  the  processor. 
Merlin  and  Vivian  are  named  for  use  in  examples. 

Figure  4-1 :  Load  Image  Creation 
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the  Kernel  optimizing  the  local  case.  The  load  image  begins  execution  in  the  Ada  Main  Unit  (after 
Kernel  initialization).  This  Main  Unit  declares,  creates,  and  schedules  the  processes  in  turn,  and 
then  declares  that  process  creation  is  completed.  After  that,  the  Main  Unit  is  descheduled  while 
the  processes  continue  to  run  independently.  The  state  transition  diagram  for  the  Main  Unit  is 
shown  in  Figure  4-2.2 

The  Main  Unit  is  responsible  for  configuring  the  processor  to  meet  the  requirements  of  the 
application.  This  must  include: 

1.  Participating  in  the  network  initialization  protocol. 

2.  Declaring  all  remote  communication  partners. 

3.  Declaring  and  creating  all  locally  executing  processes. 

There  are  several  optional  activities  that  may  be  performed  by  the  Main  Unit;  these  are: 

1.  Allocating  non-Kemel  devices  to  processes. 

2.  Reading  time-of-day  clock  (which  is  required  for  the  Main  Unit  of  the  Master 
Processor). 

3.  Reporting  system  initialization  failures  to  the  external  world. 

4.  Binding  interrupt  handlers. 

5.  Performing  any  system-dependent  initializations  (devices,  buses,  etc.). 

In  general,  the  Main  Unit  is  the  application  entity  that  is  responsible  for  configuring  the  processor 
in  the  manner  needed  by  the  application  and  can  use  any  available  Kernel  primitive. 

Given  that  there  is  one  load  image  for  each  processor,  which  creates  a  set  of  processes  as  part 
of  its  initialization,  the  issue  of  multiprogramming  is  moot.  The  user  really  considers  the  set  of 
processes  to  be  the  code  that  is  running;  the  Main  Unit  exists  only  to  ensure  that  all  the 
processes  get  linked  together  and  started. 


4.3.  System  Model 

In  light  of  the  process  model  discussed  previously,  consideration  must  be  given  to  the 
environment  in  which  these  collections  of  processes  are  executed.  This  requires  stepping  back 
from  the  "process-in-the-small"  issues  and  considering  some  system-level  or 
"process-in-the-large"  issues.  The  system  model  on  which  the  Kernel  is  based  is  shown  in  Figure 
4-3.  This  view  shows  all  that  the  Kernel  assumes  about  the  system: 

•  Three  types  of  hardware  objects  in  the  network: 

1 .  Kernel  processors 

2.  Non-Kemel  processors  or  devices  (attached  to  the  system  bus) 

3.  Devices  that  may  interrupt  a  processor 


2See  (Ward  85)  for  a  complete  description  for  the  state  transition  diagram  notation  used  in  this  document. 
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of  the  network  is 
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Figure  4-2:  Main  Unit  Outline 
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•  No  shared  memory  assumed  (or  excluded). 

•  No  mass  storage  devices  assumed  (or  excluded). 

•  Kernel  alone  interfaces  directly  to  the  system  bus. 

Given  this  model,  the  Kernel  considers  that: 

The  application  comprises  n  Kernel  processes  formed  into  m  Ada  programs  (load 
images)  running  on  m  processors. 

This  requires: 

1 .  The  user  has  a  process  or  tool  that  allows  for  the  static  distribution  of  the  m  images 
over  the  m  processors  in  the  configuration. 

2.  The  user  has  a  process  or  tool  to  download  the  images  into  processor  memory. 

3.  The  user  has  a  mechanism  to  commence  execution  of  the  loaded  programs. 

4.  The  user  has  tools  to  manipulate  all  needed  disk/tape/bulk  memory  accesses  (if 
these  are  available  in  the  embedded  configuration). 


4.4.  Error  Model 

All  Kernel  requests  are  of  the  form  P  {S}  Q;  where  P  is  the  pre-condition  to  statement  S,  and  Q  is 
the  post-condition  of  statement  S.  Errors  occur  when  one  of  the  following  conditions  exists: 

•  Pre-condition  (P)  is  false  on  call,  i.e.,  there  is  an  error  on  Kernel  invocation  ("Invalid 
request"). 

•  Pre-condition  (P)  is  asynchronously  invalidated  before  call  terminates,  i.e.,  an 
asynchronous  problem  arises  ("Sorry,  while  you  were  waiting,  something  awful 
happened"). 

•  The  post-condition  (Q)  cannot  be  established,  i.e.,  there  is  a  failure  of  the  virtual 
machine  ("Request  valid,  but  we  can't  do  it  today"). 

All  Kernel  errors  will  be  signaled  by  a  status  code  in  all  Kernel  operations  that  may  fail. 

All  Kernel  primitives  are  invoked  synchronously,  but  their  return  (or  resumption)  may  be 
asynchronous  (i.e.,  invoking  a  Kernel  primitive  may  cause  the  scheduler  to  suspend  the  invoking 
process  and  resume  a  different  process).  From  the  point  of  view  of  the  process,  the  entire 
operation  appears  to  happen  synchronously.  That  is,  the  primitives  return  to  the  caller  after  they 
have  completed  their  operation  (returning  a  success  code)  or  after  they  have  abandoned  it 
(returning  a  failure  code).  However,  their  blocking  behavior  depends  on  the  nature  of  the  errors 
that  might  occur. 

An  error  of  the  first  kind,  where  a  precondition  is  false  on  call,  always  results  in  an  immediate 
return,  without  blocking.  An  error  of  the  second  kind,  where  a  precondition  is  invalidated  before 
completion,  causes  a  return  after  some  interval  of  time,  during  which  the  caller  Is  blocked.  An 
error  of  the  third  kind  might  be  detectable  on  call  or  might  be  detected  only  after  some  time,  and 
so  the  caller  might  or  might  not  have  been  blocked. 

Wherever  possible,  errors  are  detected  locally,  by  the  Kernel  on  the  processor  running  the 
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invoking  process.  To  do  this  error  detection,  the  Kernel  relies  on  its  local  copy  of  information 
representing  global  or  remote  state.  A  rule  of  this  implementation  is  that  a  local  copy  might  lag, 
but  cannot  lead,  the  true  remote  state  it  represents.  For  example,  if  a  local  process  table  indicates 
that  a  remote  process  is  dead,  that  process  has  indeed  died.  Many  of  the  status  codes  noted  in 
this  document  are  diagnostic  in  nature  and  thus  appropriate  only  for  software  test  and  integration. 

Given  that  the  Kernel  is  intended  for  use  in  operational  real-time  systems,  there  is  a  means 
provided  to  disable  runtime  error  reporting.  The  Kernel  is  configured  so  that  each  error  code  may 
be  separately  enabled  or  disabled.  If  an  error  code  is  enabled,  the  Kernel  will  invariably  check  for 
and  report  that  error.  If  an  error  code  is  disabled,  the  Kernel  will  never  report  that  error,  even  if  it 
occurs.  In  addition,  the  Kernel  is  free  to  omit  any  checking  whose  sole  purpose  is  to  avoid 
damage  to  a  process  attempting  an  erroneous  action. 

However,  the  Kernel  will  never  omit  checks  that  guard  against  damage  to  internal  data  structures 
or  to  processes  other  than  the  one  performing  an  erroneous  action,  regardless  of  whether  the 
error  code  is  enabled  or  disabled. 


4.5.  Restrictions 

Finally,  a  number  of  restrictions  are  imposed  on  the  form  of  the  application  code.  The  following 
restrictions  are  offered,  with  justification  in  italics: 

1.  Initialization  Is  not  a  time-critical  function.  This  is  considered  to  be  a  simplification 
and  one-time  operation  done  at  system  start-up. 

2.  The  Kernel  will  not  Implement  the  Ada  tasking  semantics.  This  is  in  keeping  with  the 
Kernel's  design  goal  of  making  explicit  control  that  is  now  implicit. 

3.  No  Ada  tasking  primitives  may  be  used  by  the  application.  This  preserves  the  goal 
to  replace  the  implicit  operations  of  Ada  tasking  with  explicit  operations  of  Kernel 
processes.  A  second  reason  is  to  avoid  having  two  competing  runtime  systems  in 
the  processor  competing  for  control  of  the  hardware  clock. 

4.  All  Kernel  processes  will  be  created  statically  and  scheduled  dynamically.  This  Is 
simply  a  restriction  imposed  to  make  the  development  effort  of  the  Kernel  a 
manageable  activity. 

5.  The  Kernel  will  not  implement  fault  tolerance,  but  it  will  detect  the  presence  of 
certain  (to  be  defined)  classes  of  faults.  The  Kernel  will  detect  certain  system  faults, 
but  it  will  leave  the  recovery  from  these  faults  in  the  hands  of  the  application.  The 
Kernel  will  provide  the  capability  to  perform  fault  tolerance. 

6.  The  Kernel  will  not  use  shared  memory  between  processors.  The  Kernel's  reliance 
on  special  hardware,  such  as  shared  memory,  would  restrict  the  portability  of  the 
Kernel  and  as  such  is  disallowed. 

7.  Any  Kernel  process  may  communicate  with  any  other  Kernel  process.  Again,  this 
restriction  simplifies  the  Kernel  by  placing  the  burden  of  restricting  communications 
on  the  system  or  software  engineer.  Management  of  system  process  names  thus 
becomes  a  configuration  management  issue  within  the  application. 

8.  Inter-process  communications  will  be  provided  by  explicit  use  of  Kernel  primitives. 
Again,  this  is  a  manifestation  of  the  explicit  operation  versus  the  implicit  operation. 
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9.  Each  processor  has  its  memory  completely  loaded  at  download  time.  This  is 
another  simplifying  assumption  for  the  Kernel  implementation.  The  Kernel  will 
operate  under  the  restriction  that  all  processes  and  all  data  are  memory  resident  at 
all  times.  This  does  not  prohibit  the  application  from  building  processes  that  can  be 
rolled  in  and  out  of  memory. 

10.  The  Kernel  will  not  implement  any  paging  or  memory  management  tacilities.  The 
Kernel  assumes  all  processes  on  one  processor  execute  in  the  same  unchanging 
address  space. 
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II.  Requirements 


This  part  of  the  Kernel  Facilities  Definition  defines  the  requirements  to  be  implemented  by  the 
Kernel.  The  chapters  in  this  part  are  parallel  to  those  in  the  Kernel  primitives  part,  which  follows. 
Each  chapter  in  this  part  is  divided  into  two  sections: 

•  Behavior:  Dictates  the  functional  behavior  of  the  Kernel. 

•  Performance:  Dictates  the  performance  requirements  of  the  Kernel.  All  performance 
requirements  are  based  on  a  Motorola  68020  with  a  20  Mhz  clock  (one  wait  state). 

This  is  approximately  50  machine  instructions  for  every  12.5  ps  (assuming  5 
cycles/machine  instruction  and  20  ns/cycle). 

Section  numbers  associated  with  requirements  in  this  part  are  the  requirement  numbers 
referenced  throughout  the  remainder  of  the  document. 
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5.  General  Requirements 

The  requirements  in  this  chapter  apply  to  the  specification,  design,  and  implementation  of  the 
entire  Kernel. 

5.1.  Behavior 

5.1.1.  General  failure  reporting 

The  Kernel  shall  return  status  codes  to  the  application  program  as  a  result  of  an  invocation  of  a 
Kernel  primitive. 

5.1.2.  Kernel  priority 

Kernel  primitives  shall  execute  at  the  priority  of  the  invoking  process. 

5.1.3.  Low-level  hardware  details  isolated  from  application 

The  Kernel  shall  encapsulate  control  and  use  of  the  system  bus  (i.e.,  the  low-level  communication 
medium). 

5.1.4.  System  dependencies  Isolated 

System  dependencies  of  the  Kernel  shall  be  isolated  and  encapsulated  within  the  Kernel  code. 

5.1.5.  Kernel  provably  correct 

The  Kernel  code  shall  be  provably  correct  (except  for  termination). 

5.1.6.  Kernel  tailoring 

The  Kernel  shall  be  tailorable  (via  compilation)  to  meet  the  local  system  configuration  and  needs 
at  the  following  levels: 

1 .  Priority  range 

2.  Maximum  message  size 

3.  Maximum  number  of  process  table  entries 

4.  Maximum  size  of  the  Network  Configuration  Table  (NCT) 

5.  Default  timeslice  quantum 

6.  Default  message  queue  size 

5.1.7.  Kernel  modularity 

The  Kernel  shall  be  developed  such  that  an  application  program  has  to  import  only  those  Kernel 
primitive  capabilities  that  it  needs. 
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5.1.8.  Run-time  error  checking 

The  Kernel  shall  provide  the  capability  to  disable  all  error  checking  and  reporting. 


5.2.  Performance 

5.2.1.  Kernel  size 

The  Kernel  shall  use  no  more  than  5%  of  the  total  available  system  memory  for  Kernel  code. 

5.2.2.  Kernel  internal  data  size 

The  Kernel  shall  use  no  more  than  5%  of  the  total  available  system  memory  for  Kernel  data. 

5.2.3.  Kernel  stack  for  Kernel  invocation 

The  Kernel  shall  use  no  more  than  100  bytes  of  process  stack  space  for  a  Kernel  primitive 
invocation. 

5.2.4.  Linear  performance 

The  time  performance  of  all  Kernel  algorithms  shall  be  better  than  linear  in  the  number  of 
processes. 

5.2.5.  Kernel  algorithm  documentation 

All  Kernel  algorithms  shall  be  fully  documented  in  the  Kernel  User’s  Manual [kum  88]. 
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6.  Processor  Requirements 


6.1.  Behavior 

6.1.1.  Master  processor  identification 

The  Kernel  shall  provide  the  capability  for  exactly  one  processor  to  identify  itself  as  the  network 
Master  processor  for  initialization  purposes. 

6.1.2.  Subordinate  processor  identification 

The  Kernel  shall  provide  the  capability  for  all  other  processors  to  identify  themselves  as 
subordinate  to  the  network  Master  processor  for  initialization  purposes. 

6.1.3.  Processor  failure  detection 

The  Kernel  shall  detect  the  failure  of  any  processor  in  the  network  to  initialize. 

6.1.4.  Processor  failure  reporting 

The  Kernel  shall  report  to  the  Master  processor  the  failure  of  any  processor  in  the  network  to 
initialize. 

6.1.5.  Network  clock  synchronization  at  initialization 

The  Kernel  shall  provide  the  capability  to  synchronize  all  network  clocks  at  system  initialization. 

6.1.6.  Ciock  synchronization  not  enforced  after  initialization 

The  Kernel  shall  not  enforce  clock  synchronization  across  processors  after  Initial  synchronization. 

6.1.7.  Network  failure  not  detected 

The  Kernel  shall  not  be  required  to  detect  network  failure. 

6.1.8.  Network  integrity  not  provided 

The  Kernel  shall  not  provide  network  integrity  controls. 

6.1.9.  Network  integrity  primitives  provided 

The  Kernel  shall  provide  the  capability  for  the  user  to  implement  network  integrity  consistent  with 
the  needs  of  the  application. 

6.1.10.  Network  configuration  primitives  provided 

The  Kernel  shall  provide  the  capability  for  the  application  to  specify  the  network  configuration 
including: 

1.  Device  identifier 

2.  Physical  address 

3.  Processor  device 

4.  Other  data  required  for  network  operation 
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6.1.11.  Low-ievei  network  details  isolated  from  application 

The  Kernel  shall  isolate  low-level  network  implementation  knowledge  from  the  user  application. 


6.2.  Performance 

6.2.1.  System  initialization  not  time-critical 

System  initialization  shall  be  accomplished  in  less  than  5  seconds. 

6.2.2.  Initial  time  delta  across  the  network 

Deleted  - 1  July  1988.3 


Subsumed  by  Synchronize  primitive  (21.1 .6). 
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7.  Process  Requirements 


7.1.  Behavior 

7.1.1.  Main  Unit  identification 

There  shall  be  a  single  Main  Unit  on  each  processor  that  coordinates  processor-level 
initialization. 

7.1.2.  Main  Unit  profile 

The  Main  Unit  shall  be  an  Ada  procedure  with  no  parameters. 

7.1.3.  Identification  of  communication  partners 

The  Kernel  shall  provide  the  capability  for  the  Main  Unit  to  identify  all  Kernel  processes  and 
non-CPU  devices  with  which  communication  from  this  processor  is  to  occur. 

7.1.4.  Create  process 

The  Kernel  shall  provide  the  capability  for  the  Main  Unit  to  create  independent,  concurrent 
threads  of  control  (i.e.,  processes). 

7.1.5.  Ada  process  profile 

The  code  of  a  process  shall  be  an  Ada  procedure  with  no  parameters. 

7.1.6.  Process  stack  size 

The  Kernel  shall  provide  the  capability  for  the  Main  Unit  to  specify  the  process  stack  size  for  each 
created  process. 

7.1.7.  Process  stack  size  fixed 

The  process  stack  size  shall  be  fixed  at  process-creation  time. 

7.1.8.  Default  process  stack  size 

The  default  process  stack  size  shall  be  64  bytes. 

7.1.9.  Message  queue  size 

The  Kernel  shall  provide  the  capability  for  the  Main  Unit  to  specify  the  input  message  queue  size 
for  each  created  process. 

7.1.10.  Message  queue  size  fixed 

The  process  message  queue  size  shall  be  fixed  at  process-creation  time. 


CMU/SEI-88-TR-1 6 


27 


7.1.11.  Default  message  queue  size 

The  default  input  message  queue  size  shall  be  256  bytes. 

7.1.12.  Non-propagation  of  exceptions 

The  Kernel  shall  ensure  that  exceptions  are  not  propagated  outside  the  scope  of  the  process  in 
which  they  are  raised. 

7.1.13.  Abortion  on  iiiegal  exception  propagation 

The  Kernel  shall  abort  any  process  that  attempts  to  propagate  an  exception  outside  the  scope  of 
the  process. 

7.1.14.  Allocate  device 

The  Kernel  shall  provide  the  capability  for  a  process  to  identify  itself  as  the  sole  receiver  of 
messages  for  a  non-Kemel  device. 

7.1.15.  Successful  initialization 

The  Kernel  shall  provide  the  capability  for  the  Main  Unit  to  Inform  the  other  processors  of  the 
successful  initialization  of  its  processor. 

7.1.16.  Ensure  network-wide  Initialization  completed 

The  Kernel  shall  ensure  that  no  process  executes  until  all  necessary  network-wide  initializations 
are  complete. 

7.1.17.  Main  Unit  termination 

Upon  successful  completion  of  processor  initialization,  the  Main  Unit  shall  be  terminated. 

7.1.18.  Process  seif-termination 

The  Kernel  shall  provide  the  capability  for  a  process  to  terminate  itself  in  an  orderly  manner. 

7.1.19.  Process  seif-abortion 

The  Kernel  shall  provide  the  capability  for  a  process  to  abort  itself. 

7.1.20.  Aborting  another  process 

The  Kernel  shall  provide  the  capability  for  one  process  to  abort  another  process. 

7.1.21.  Pending  messages  for  terminated  process  discarded 

The  Kernel  shall  ensure  that  messages  pending  for  a  terminated  process  are  discarded. 

7.1.22.  Pending  messages  for  aborted  process  discarded 

The  Kernel  shall  ensure  that  messages  pending  for  an  aborted  process  are  discarded. 
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7.1.23.  Identify  self 

The  Kernel  shall  provide  the  capability  for  a  process  to  obtain  its  own  identity. 

7.1.24.  Identify  another  process 

The  Kernel  shall  provide  the  capability  for  a  process  to  obtain  the  identity  of  another  process  in 
the  network. 

7.1.25.  Process  failure  detection 

The  Kernel  shall  provide  the  capability  to  detect  the  failure  of  any  process  in  the  network. 

7.1.26.  Process  failure  reporting 

The  Kernel  shall  report  the  detected  failure  of  any  process  in  the  network. 

7.2.  Performance 

7.2.1.  Time  to  create  process 

The  creation  of  a  process  shall  take  no  more  than  60  ps. 

7.2.2.  Time  to  terminate  process 

The  termination  of  a  process  shall  take  no  more  than  30  ps. 

7.2.3.  Time  to  abort  process 

The  abortion  of  a  process  shall  take  no  more  than  30  ps.4 

7.2.4.  Time  to  allocate  device 

The  allocation  of  a  device  to  a  process  shall  take  no  more  than  20  ps. 

7.2.5.  Kernel  data  for  each  active  process 

The  Kernel  shall  use  no  more  than  100  bytes  of  data  for  Kernel  data  structures  for  each  active 
process. 

7.2.6.  Kernel  stack  for  each  active  process 

The  Kernel  shall  use  no  more  than  64  bytes  of  process  stack  space  for  each  process. 


4Network  communication  overhead  is  not  included. 
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8.  Semaphore  Requirements 


8.1.  Behavior 

8.1.1.  Create  a  semaphore 

The  Kernel  shall  provide  the  capability  to  create  a  semaphore  object. 

8.1.2.  Creation  semantics 

The  creation  of  a  semaphore  shall  associate  an  empty  waiting  process  queue  with  the 
semaphore  object. 

8.1.3.  Semaphore  queue  FIFO 

The  waiting  process  queue  shall  be  first  in,  first  out  (FIFO)  ordered. 

8.1.4.  Claiming  a  semaphore 

The  Kernel  shall  provide  the  capability  for  a  process  to  obtain  access  to  a  previously  created 
semaphore. 

8.1.5.  Claim  timeout  after  duration 

The  Kernel  shall  provide  the  capability  for  a  claim  operation  to  terminate  after  a  specified  duration 
if  the  semaphore  does  not  become  available. 

8.1.6.  Claim  timeout  at  specific  time 

The  Kernel  shall  provide  the  capability  for  a  claim  operation  to  terminate  at  a  specific  absolute 
time  if  the  semaphore  does  not  become  available. 

8.1.7.  Resumption  priority  after  claim 

The  Kernel  shall  provide  the  capability  for  the  claiming  process  to  specify  a  priority  at  which  it  is  to 
be  unblocked. 

8.1.8.  Claiming  an  available  semaphore 

Claiming  an  available  semaphore  shall  immediately  give  control  of  the  semaphore  to  the  invoking 
process  and  shall  mark  the  semaphore  as  unavailable. 

8.1.9.  Claiming  an  unavailable  semaphore 

Claiming  an  unavailable  semaphore  shall  immediately  block  the  invoking  process  until  the 
semaphore  becomes  available  or  the  timeout  expires. 

8.1.10.  Releasing  a  semaphore 

The  Kernel  shall  provide  the  capability  for  a  process  to  relinquish  control  of  a  previously  claimed 
semaphore. 
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8.1.11.  Release  semantics 

Releasing  a  semaphore  shall  allow  the  Kernel  to  give  control  of  the  semaphore  to  the  process  at 
the  head  of  the  waiting  process  queue. 

8.2.  Performance 

8.2.1.  Time  to  create  a  semaphore 

Creating  a  semaphore  object  shall  take  no  more  than  25  ns. 

8.2.2.  Time  to  claim  a  semaphore 

Claiming  a  semaphore  object  shall  take  no  more  than  25  ns.5 

8.2.3.  Time  to  release  a  semaphore 

Releasing  a  semaphore  object  shall  take  no  more  than  25  ns.6 


5No  scheduling  activity  is  involved. 

®No  scheduling  activity  is  involved. 
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9.  Scheduling  Requirements 


9.1.  Behavior 

9.1.1.  initial  scheduling  parameters 

The  Kernel  shall  provide  the  capability  for  each  Main  Unit  to  specify  the  initial  scheduling 
parameters  of  each  process  to  execute  on  that  processor. 

9.1.2.  Default  schedule  parameters 

The  default  schedule  parameters  of  a  process  shall  be  preemptable,  interruptible,  and  lowest 
possible  priority. 

9.1.3.  Representation  of  priority 

Process  priorities  shall  be  represented  as  a  subset  of  the  positive  integers. 

9.1.4.  Definition  of  priority  range 

The  range  of  priorities  shall  be  defined  at  compile  time  by  the  user(s)  of  the  Kernel. 

9.1.5.  Definition  of  priority  ordering 

Smaller  integer  values  for  priority  shall  represent  higher  process  priorities. 

9.1.6.  Dynamic  process  priority 

The  Kernel  shall  provide  the  capability  to  set  process  priorities  dynamically. 

9.1.7.  Set  initial  priority 

The  Kernel  shall  provide  the  capability  to  set  the  initial  process  priority  at  process-creation  time. 

9.1.8.  Change  priority 

The  Kernel  shall  provide  the  capability  for  a  process  to  change  its  own  process  priority. 

9.1.9.  Query  priority 

The  Kernel  shall  provide  the  capability  for  a  process  to  query  its  own  process  priority. 

9.1.10.  Definition  of  preemption 

The  Kernel  shall  provide  two  preemption  states:  preemptable  by  a  process  of  the  same  priority, 
and  not  preemptable  by  a  process  of  the  same  priority. 

9.1.11.  Set  initial  preemption 

The  Kernel  shall  provide  the  capability  to  set  the  initial  preemption  state  at  process-creation  time. 
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9.1.12.  Change  preemption 

The  Kernel  shall  provide  the  capability  for  a  process  to  set  its  own  preemption  state. 

9.1.13.  Query  preemption 

The  Kernel  shall  provide  the  capability  for  a  process  to  query  its  own  preemption  state. 

9.1.14.  Definition  of  wait 

The  Kernel  shall  provide  the  capability  for  a  process  to  voluntarily  relinquish  control  of  the 
processor  and  to  be  resumed  at  the  next  sequential  statement. 

9.1.15.  Walt  for  duration 

The  Kernel  shall  provide  the  capability  for  a  process  to  block  its  own  execution  for  a  specified 
duration. 

9.1.16.  Wait  until  specified  time 

The  Kernel  shall  provide  the  capability  for  a  process  to  block  its  own  execution  until  a  specified 
time. 

9.1.17.  Resumption  priority  after  wait 

The  Kernel  shall  provide  the  capability  for  a  waiting  process  to  specify  a  priority  at  which  it  is  to  be 
unblocked. 

9.1.18.  Set  tlmeslice 

The  Kernel  shall  provide  the  capability  to  set  the  timeslice  quantum  for  each  processor. 

9.1.19.  Enable  round-robin  time  slicing 

The  Kernel  shall  provide  the  capability  to  enable  the  time  slicing  of  processes  of  equal  priorities  in 
a  round-robin  manner. 

9.1.20.  Disable  round-robin  time  slicing 

The  Kernel  shall  provide  the  capability  to  disable  time  slicing  of  processes  of  equal  priorities  in  a 
round-robin  manner. 

9.1.21.  Default  timeslice  settings 

The  default  timeslice  settings  shall  be:  time  slicing  disabled,  and  timeslice  quantum  is  zero. 

9.1.22.  Setting  another  process’s  scheduling  parameters  prohibited 

The  Kernel  shall  prohibit  one  process  from  directly  setting  another's  scheduling  parameters  (e.g., 
priority,  preemption)  with  the  exception  of  the  initial  scheduling  parameters,  which  are  defined  by 
the  Main  Unit  at  process-creation  time. 
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9.1.23.  Process  states 

A  process  shall  always  be  in  one  of  four  definite  states: 

1 .  Running 

2.  Dead 

3.  Blocked 

4.  Suspended 

9.1.24.  Scheduling  algorithms 

The  Kernel  scheduling  algorithms  shall  be: 

1 .  Deterministic,  and 

2.  Of  predictable  performance. 

9.1.25.  Scheduling  algorithms  provided 

The  scheduling  algorithms  shall  provide  priority-based,  preemptive  scheduling, 

9.1.26.  Documentation  of  scheduling  algorithms 

The  Kernel  scheduling  algorithms  shall  be  fully  documented  in  the  Kernel  User’s  Manual. 

9.1.27.  Meaning  of  a  timesiice 

A  process  that  is  preemptable  while  timeslicing  is  enabled  shall  execute  for  no  more  than  one 
timesiice  quantum  before  a  forced  reschedule  point  occurs. 

9.2.  Performance 

9.2.1 .  Time  to  set  priority 

Setting  a  process  priority  shall  take  no  more  than  57  ps.7 

9.2.2.  Time  to  set  preemption 

Setting  a  process  preemption  state  shall  take  no  more  than  18  ps.8 

9.2.3.  Time  to  suspend  process 

Suspension  of  a  process  shall  take  no  more  than  43  ps. 


7No  scheduling  activity  is  involved. 

aNo  scheduling  activity  is  involved. 
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9.2.4.  Time  to  resume  process 

Resumption  of  a  process  shall  take  no  more  than  33  ns. 

9.2.5.  Time  to  enable  or  disable  time  slicing 

Enabling  or  disabling  timeslice  scheduling  shall  take  no  more  than  18  ps.9 

9.2.6.  Time  of  context  switch 

The  time  needed  to  suspend  execution  of  the  currently  running  process  and  resume  execution  of 
a  different  process  shall  take  no  more  than  76  ps.10 

9.2.7.  Dispatch  time 

The  Kernel  shall  take  no  more  than  33  ps  to  dispatch  the  highest  priority  task  after  it  becomes 
unblocked. 


®No  scheduling  activity  is  involved. 

10Requirement  9.2.3  time  +  requirement  9.2.4  time. 
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10.  Communication  Requirements 


10.1.  Behavior 

10.1.1.  Reference  communication  partners 

The  Kernel  shall  provide  the  capability  for  a  process  to  reference  all  other  processes  with  which  it 
communicates. 

10.1.2.  Send 

The  Kernel  shall  provide  the  capability  for  a  process  to  send  data  to  another  process. 

10.1.3.  Send  with  ACK 

The  Kernel  shall  provide  the  capability  for  the  sending  process  to  request  acknowledgment  (ACK) 
of  message  receipt  by  the  receiving  process. 

10.1.4.  Resumption  priority  for  send  with  ACK 

The  Kernel  shall  provide  the  capability  for  the  sending  process  to  specify  the  priority  at  which  it  is 
to  be  unblocked. 

10.1.5.  Sender  specifies  recipient 

The  process  originating  a  message  sent  to  a  single  recipient  shall  specify  the  recipient. 

10.1.6.  Receiver  physical  address  hidden 

The  sender  shall  not  need  to  know  the  physical  network  address  of  the  receiver. 

10.1.7.  Send  timeout  after  specified  duration 

The  Kernel  shall  provide  the  capability  for  a  process  to  terminate  a  send  with  ACK  operation  if  the 
message  is  not  received  after  a  specified  duration. 

10.1.8.  Send  timeout  by  specified  time 

The  Kernel  shall  provide  the  capability  for  a  process  to  terminate  a  send  with  ACK  operation  if  the 
message  Is  not  received  by  a  specified  time. 

10.1.9.  Send  timeout  reporting 

The  Kernel  shall  terminate  send  operations  whose  timeout  expires  with  a  status  code. 

10.1.10.  Send  recipient  failure  detection 

The  Kernel  shall  detect  the  failure  of  the  receiving  process  during  a  send  with  ack  operation. 


CMU/SEI-88-TR-1 6 


37 


10.1.11.  Send  recipient  failure  reporting 

The  Kernel  shall  report  the  failure  of  a  message  recipient  during  a  send  with  ACK  operation. 

10.1.12.  Receive 

The  Kernel  shall  provide  the  capability  for  a  process  to  receive  data  from  another  process  by 
copying  the  data  into  the  work  space  of  the  invoking  process. 

10.1.13.  Resumption  priority  for  receive 

The  Kernel  shall  provide  the  capability  for  the  receiving  process  to  specify  the  priority  at  which  it 
is  to  be  unblocked. 

10.1.14.  Kernel  identifies  sender 

The  Kernel  shall  inform  the  message  recipient  of  the  sender’s  identity. 

10.1.15.  Sender  physical  address  hidden 

The  receiver  shall  not  need  to  know  the  physical  network  address  of  the  sender. 

10.1.16.  Receive  timeout  after  specified  duration 

The  Kernel  shall  provide  the  capability  for  a  process  to  terminate  a  receive  operation  if  it  is  not 
completed  after  a  specified  duration. 

10.1.17.  Receive  timeout  by  specified  time 

The  Kernel  shall  provide  the  capability  for  a  process  to  terminate  a  receive  operation  if  it  is  not 
completed  by  a  specified  time. 

10.1.18.  Receive  timeout  reporting 

The  Kernel  shall  terminate  with  a  status  code  a  receive  operation  whose  timeout  expires. 

10.1.19.  Message  format 

The  Kernel  shall  not  impose  any  restrictions  on  the  content,  format,  or  length  of  a  message  other 
than  maximum  message  size  limitations. 

10.1.20.  Message  too  big  on  receive 

Any  attempt  to  receive  a  message  larger  than  the  object  into  which  it  is  to  be  put  shall  result  in 
the  message  contents  being  discarded,  but  the  message  attributes  shall  be  delivered  to  the 
receiver.  These  include: 

1.  Message  sender’s  process  identifier 

2.  Message  tag 

3.  Message  length 
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10.1.21.  FIFO  message  queue 

The  process  message  queue  shall  be  FIFO  ordered. 

10.1.22.  Message  queue  overflow 

The  Kernel  shall  provide  two  options  for  managing  the  message  queue  when  the  arrival  of  a  new 
message  would  cause  queue  overflow: 

1 .  Accept  the  new  message  by  overwriting  old  messages;  or 

2.  Reject  the  new  message. 

10.1.23.  Default  overflow  handling 

The  default  option  for  managing  message  queue  overflow  shall  be  to  reject  the  new  message. 

10.1.24.  Status  code  on  queue  overflow 

The  Kernel  shall  return  a  status  code  on  the  first  receive  operation  after  queue  overflow  has 
occurred. 

10.1.25.  Communication  failure  reporting 

The  Kernel  shall  terminate  pending  communication  operations  with  a  failed  process  with  a  status 
code  when  that  failure  is  detected. 

10.1.26.  Communication  with  non-Kernel  devices 

The  Kernel  shall  provide  the  capability  to  communicate  with  any  device  (capable  of  sending  or 
receiving  communication)  in  the  network. 

10.1.27.  Communication  deadlock  detection 

The  Kernel  shall  prohibit  a  process  from  performing  a  send  with  ack  operation  to  itself. 

10.1.28.  Common  primitives  for  all  communication 

The  Kernel  shall  provide  a  common  set  of  communication  primitives  for  both  local  and  remote 
message  passing. 

10.1.29.  Local  communication  optimization 

The  Kernel  shall  optimize  communications  local  within  a  processor. 

10.1.30.  Message  integrity 

The  Kernel  shall  ensure  message  integrity,  including: 

1 .  The  entire  message  reaches  the  receiver;  and 

2.  Simple  transmission  errors  are  detected. 
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10.1.31.  Communication  integrity 

The  Kernel  shall  ensure  communication  integrity,  including: 

1 .  The  sender  of  a  message  is  a  valid  process;  and 

2.  The  receiver  of  a  message  is  a  valid  process. 


10.2.  Performance 

10.2.1.  Transmission  time  of  0-iength  message 

The  time11  needed  to  send  a  0-length  message  without  acknowledgment  to  a  single  process  in 
the  case  of  two  processes  on  two  processors  (excluding  network  transmission  time)  shall  be  no 
more  than  25  ps. 

10.2.2.  Transmission  time  of  iarge  message 

The  time  needed  to  send  a  large12  message  without  acknowledgment  to  a  single  process  in  the 
case  of  two  processes  on  two  processors  (excluding  network  transmission  time)  shall  be  no  more 
than  25  ps. 

10.2.3.  Transmission  time  of  0-iength  message  with  ACK 

The  time  needed  to  send  a  0-length  message  with  acknowledgment  to  a  single  process  waiting 
for  that  message  in  the  case  of  two  processes  on  two  processors  (excluding  network 
transmission  time)  shall  be  no  more  than  50  ps. 

10.2.4.  Transmission  time  of  iarge  message  with  ACK 

The  time  needed  to  send  a  large  message  with  acknowledgment  to  a  single  process  waiting  for 
that  message  in  the  case  of  two  processes  on  two  processors  (excluding  network  transmission 
time)  shall  be  no  more  than  50  ps. 

10.2.5.  Transmission  time  of  0-iength  message  iocaiiy 

The  time  needed  to  send  a  0-length  message  without  acknowledgment  to  a  single  process  in  the 
case  of  two  processes  on  the  same  processor  shall  be  no  more  than  1 5  ps. 

10.2.6.  Transmission  time  of  iarge  message  iocaiiy 

The  time  needed  to  send  a  large  message  without  acknowledgment  to  a  single  process  in  the 
case  of  two  processes  on  the  same  processor  shall  be  no  more  than  1 5  ps. 


1  ’All  times  exdude  copy  time,  which  is  to  be  determined  (TBD)  (is/byte,  and  net  transmission  time,  which  is  TBD 
^is/byte. 

12The  actual  size  of  a  "large"  message  is  TBD.  The  intent  is  to  select  a  message  size  that  places  a  non-trivia!  load  on 
the  system. 
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10.2.7.  Transmission  time  of  0-length  message  locally  with  ACK 

The  time  needed  to  send  a  0-length  message  with  acknowledgment  to  a  single  process  waiting 
for  that  message  in  the  case  of  two  processes  on  the  same  processor  shall  be  no  more  than  20 
ps. 

10.2.8.  Transmission  time  of  large  message  locally  with  ACK 

The  time  needed  to  send  a  large  message  with  acknowledgment  to  a  single  process  waiting  for 
that  message  in  the  case  of  two  processes  on  the  same  processor  shall  be  no  more  than  20  ps. 

10.2.9.  Time  to  receive  0-iength  message 

The  Kernel  overhead  time  needed  to  receive  a  0-length  available  message  shall  be  no  more  than 
25  ps. 

10.2.10.  Time  to  receive  large  message 

The  Kernel  overhead  time  needed  to  receive  a  large  available  message  shall  be  no  more  than  25 
ps. 

10.2.11.  Fixed  message  overhead 

The  Kernel  shall  use  no  more  than  128  bits/message. 
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11.  Interrupt  Requirements 


11.1.  Behavior 

11.1.1.  Interrupt  names 

The  Kernel  shall  accept  a  system.address  as  an  interrupt  identification  (i.e.,  name). 

11.1.2.  No  exception  propagation  from  Interrupt  handlers 

No  exceptions  shall  be  propagated  out  of  the  scope  of  an  interrupt  handler. 

11.1.3.  Exit  on  exception  propagation  from  interrupt  handlers 

Any  attempt  to  propagate  an  exception  outside  the  scope  of  an  interrupt  handler  shall  result  in  the 
immediate  return  from  the  interrupt  handler. 

11.1.4.  Enable  interrupt 

The  Kernel  shall  provide  the  capability  for  a  process  to  enable  an  interrupt. 

11.1.5.  Disable  Interrupt 

The  Kernel  shall  provide  the  capability  for  a  process  to  disable  an  interrupt. 

11.1.6.  Default  status  of  Interrupts 

All  interrupts  visible  to  the  user  code  shall  have  the  default  status  defined  by  the  user  and  the 
system  hardware. 

11.1.7.  Query  Interrupt  status 

The  Kernel  shall  provide  the  capability  for  a  process  to  query  the  enabled/disabled  status  of  an 
interrupt. 

11.1.8.  Simulate  Interrupt 

The  Kernel  shall  provide  the  capability  for  a  process  to  simulate  any  interrupt  in  software. 

11.1.9.  Define  Interrupt  handier  In  Ada 

The  Kernel  shall  provide  the  capability  for  a  process  to  define  an  interrupt  handler  in  Ada. 

11.1.10.  Ada  Interrupt  handler  profile 

The  Ada  interrupt  handler  shall  be  a  procedure  with  no  parameters. 

11.1.11.  Bind  Interrupt  handler 

The  Kernel  shall  provide  the  capability  to  define  an  Ada  code  unit  as  an  interrupt  handler  for  a 
specific  interrupt. 
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11.1.12.  Blocking  prohibited  in  interrupt  handier 

Within  an  interrupt  handler,  any  attempt  to  invoke  a  blocking  Kernel  primitive  in  a  situation  where 
it  would  block  shall  be  terminated  immediately  with  a  status  code. 

11.1.13.  interrupts  not  queued 

The  Kernel  shall  not  queue  pending  interrupts. 

11.1.14.  Interrupt  implementation  visibility 

The  Kernel  shall  allow  the  user  unhindered  access  to  the  underlying  hardware  implementation  of 
interrupts. 

11.1.15.  interrupt  priority 

All  interrupt  handlers  shall  execute  at  a  higher  priority  than  any  Kernel  process. 


11.2.  Performance 

11.2.1:  Time  to  enter  interrupt  handier 

The  time  needed  to  enter  an  interrupt  handler  (from  moment  of  preemption  until  the  first 
statement  of  the  handler  is  executed)  shall  be  less  than  15  ps.13 

11.2.2.  Time  to  exit  interrupt  handier 

The  time  needed  to  exit  an  Interrupt  handler  (from  the  return  from  interrupt  until  the  resumption  of 
the  preempted  process)  shall  be  less  than  10  ps. 

11.2.3.  Time  to  bind  interrupt  handier 

The  time  needed  to  bind  an  interrupt  handler  shall  be  less  than  20  ps. 

11.2.4.  Interrupt  stack  use 

The  Kernel  shall  use  no  more  than  16  bytes14  of  process  stack  space  per  interrupt  handler 
invocation. 


13No  context  save  is  included  in  this  time. 

14No  context  data  are  included  in  this  allocation. 
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12.  Time  Requirements 


12.1.  Behavior 

12.1.1.  Package  Calendar 

The  Kernel  shall  support  the  standard  Ada  package  Calendar  (see  [alrm  83],  Section  9.6). 

12.1.2.  Exclusion  of  Package  Calendar 

The  Kernel  shall  not  require  that  package  Calendar  be  a  part  of  the  load  image. 

12.1.3.  Use  of  real-time  clock 

The  Kernel  shall  be  capable  of  using  a  real-time  clock. 

12.1.4.  Definition  of  TICK 

The  Kernel  shall  define  a  constant,  TICK,  that  is  the  smallest  resolvable  interval  of  time. 

12.1.5.  Definition  of  SLICE 

The  Kernel  shall  provide  a  constant,  SLICE,  that  is  the  smallest  schedulable  interval  of  time. 

12.1.6.  Relationship  between  TICK  and  SLICE 

SLICE  shall  be  an  integral  multiple  of  TICK. 

12.1.7.  TICK  used  internally 

The  Kernel  shall  Internally  maintain  time  events  accurate  to  the  TICK. 

12.1.8.  SLICE  basis  for  scheduling 

The  Kernel  shall  truncate  all  scheduling  times  (e.g.,  durations)  to  the  nearest  SLICE. 

12.1.9.  Two  kinds  of  delays 

The  Kernel  shall  support  two  kinds  of  delays: 

1 .  Delay  for  a  specified  duration  (i.e.,  the  Ada  type  duration)  -,  and 

2.  Delay  until  a  specified  time  (i.e.,  the  Ada  type  time). 

12.1.10.  Adjust  local  processor  time 

The  Kernel  shall  provide  the  capability  to  adjust  (increment  and  decrement)  local  elapsed 
processor  time. 

12.1.11.  Effect  of  adjusting  local  processor  time 

Adjusting  local  processor  time  shall  affect  all  waiting  events  (i.e.,  those  waiting  for  and  those 
waiting  until) . 
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12.1.12.  Reset  epoch  time 

The  Kernel  shall  provide  the  capability  to  reset  the  processor  epoch15  time. 

12.1.13.  Effect  of  resetting  epoch  time 

Resetting  epoch  time  shall  affect  only  those  events  waiting  until  a  specified  time. 

12.1.14.  Time  base  reference 

The  time  base  reference  shall  be  Julian  day  1  (l.e.,  1200  on  1  January  4713BCE;  see  Joseph 
Justus  Scaliger,  De  emendatione  temporum,  1582). 

12.1.15.  Read  ciock 

The  Kernel  shall  provide  the  capability  to  read  current  elapsed  time  (in  TICKs) . 

12.1.16.  Clock  synchronization 

The  Kernel  shall  provide  the  capability  to  synchronize  all  the  local  clocks  on  Kernel  processors  in 
the  network  to  the  time  of  the  invoking  processor. 

12.1.17.  Definition  of  synchronization 

Synchronization  of  all  network  clocks  shall  force: 

1 .  All  epoch  times  to  be  set  to  the  epoch  time  on  the  invoking  processor. 

2.  All  elapsed  times  to  be  identical  to  the  elapsed  time  on  the  invoking  processor, 
within  the  delta  defined  In  12.2.5. 

12.1.18.  Synchronize  timeout  after  duration 

The  Kernel  shall  provide  the  capability  for  a  synchronize  operation  to  terminate  after  a  specified 
duration  if  the  synchronization  protocol  has  not  successfully  completed. 

12.1.19.  Synchronize  timeout  at  specific  time 

The  Kernel  shall  provide  the  capability  for  a  synchronize  operation  to  terminate  at  a  specific 
absolute  time  if  the  synchronization  protocol  has  not  successfully  completed. 

12.1.20.  Resumption  priority  after  synchronize 

The  Kernel  shall  provide  the  capability  for  the  synchronizing  process  to  specify  a  priority  at  which 
it  is  to  be  unblocked. 

12.1.21.  Duplicate  synchronization  rejected 

The  Kernel  shall  reject  an  invocation  of  the  sychronize  primitive  while  a  previous  invocation  is  in 
progress. 


15See  Chapter  21  for  the  definition  of  epoch  time. 
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12.2.  Performance 


12.2.1.  Time  to  adjust  local  processor  time 

The  time  needed  to  adjust  the  local  processor  time  shall  be  no  more  than  18  ps.16 

12.2.2.  Time  to  reset  epoch  time 

The  time  needed  to  reset  the  epoch  time  shall  be  no  more  than  18  ps.17 

12.2.3.  Time  to  read  clock 

The  time  needed  to  read  the  clock  shall  be  no  more  than  18  ps. 

12.2.4.  Time  to  synchronize 

The  time  needed  to  synchronize  all  local  processor  clocks  shall  be  no  more  than  200  ps.10 

12.2.5.  Accuracy  of  time  synchronization 

After  synchronization  all  processor  clocks  shall  be  within  TBD  ps. 


ieNo  scheduling  activity  is  involved. 

17No  scheduling  activity  is  involved. 

18This  is  4  *  (time  needed  to  send  a  0-length  message);  see  requirement  10.2.3  in  Chapter  10. 
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13.  Alarm  Requirements 


13.1.  Behavior 

13.1.1.  Maximum  number  of  alarms 

The  user  shall  be  able  to  define  one  alarm  per  process. 

13.1.2.  Reiative  aiarm  time 

The  Kernel  shall  provide  the  capability  to  set  an  alarm  to  expire  after  a  specified  duration. 

13.1.3.  Absolute  alarm  time 

The  Kernel  shall  provide  the  capability  to  set  an  alarm  to  expire  at  a  specified  time. 

13.1.4.  Kernel  defined  alarm  exception 

The  Kernel  shall  define  an  alarm_explred  exception. 

13.1.5.  Expiration  of  alarm 

The  expiration  of  an  alarm  shall  raise  the  alarm_explred  exception. 

13.1.6.  Resumption  priority  after  transfer 

When  a  process  sets  an  alarm,  it  shall  have  the  capability  to  specify  a  priority  at  which  it  is  to  be 
unblocked. 

13.1.7.  Set  alarm  for  zero  seconds 

Setting  an  alarm  to  expire  in  zero  time  units  shall  immediately  raise  the  alarm_explred  exception. 

13.1.8.  Set  alarm  for  non-future  duration 

Setting  an  alarm  to  expire  after  some  non-future  duration  shall  immediately  raise  the 
alarm_explred  exception. 

13.1.9.  Set  alarm  for  time  in  past 

Setting  an  alarm  to  expire  at  some  time  in  the  past  shall  immediately  raise  the  alarm_explred 
exception. 

13.1.10.  Cancel  alarm 

The  Kernel  shall  provide  the  capability  to  cancel  an  unexpired  alarm. 
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13.2.  Performance 


13.2.1.  Time  to  set  alarm 

Setting  an  alarm  shall  take  no  more  than  10  fis. 

13.2.2.  Time  to  cancel  alarm 

Canceling  an  alarm  shall  take  no  more  than  1 0  ps. 

13.2.3.  Time  to  transfer  to  exception  handler 

The  time  needed  to  raise  the  alarm_explred  exception  and  transfer  control  to  the  inner-most 
enclosing  exception  handler  shall  take  no  more  than  TBD19  ps. 


19This  is  compiler-dependent  and  not  under  the  control  of  the  Kernel. 
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14.  Tool  Interface 


The  requirements  in  this  chapter  are  not  mapped  on  the  Kernel  primitives  in  Chapters  15-22,  nor 
are  the  tool  interface  primitives  mapped  onto  the  other  requirements.  The  tool  interface  is  a 
non-essential  part  of  the  Kernel,  and  its  existence  is  not  needed  for  the  proper  use  and 
functioning  of  the  Kernel. 


14.1.  Behavior 

14.1.1.  Monitoring 

The  Kernel  shall  provide  the  capability  to  monitor  certain  internal  data  and  primitive  operations. 

14.1.2.  Monitor  process 

The  monitor  shall  be  a  process. 

14.1.3.  Number  of  monitors 

The  application  may  have  any  number  of  monitor  processes  within  the  application-defined 
constraints. 

14.1.4.  Monitor  process  Is  local 

The  monitor  process  shall  be  local  to  the  processor  it  is  monitoring. 

14.1.5.  Asynchronous  logging 

The  Kernel  shall  log  the  monitored  data  by  sending  a  message  to  the  local  monitor  process. 

14.1.6.  Monitor  process  attributes 

The  Kernel  shall  provide  the  capability  to  monitor  process  attributes  of  any  declared  process. 

14.1.7.  Specify  processes  to  monitor 

The  Kernel  shall  provide  the  capability  to  specify  the  processes  on  which  monitoring  is  to  occur. 

14.1.8.  Disable  monitoring  of  process  attributes 

The  Kernel  shall  provide  the  capability  to  disable  monitoring  process  attributes. 

14.1.9.  Process  attributes  available 

The  process  attributes  that  shall  be  available  for  monitoring  are: 

1 .  Process  identifier 

2.  Process  state 

3.  Time  process  entered  state 

4.  Process  priority 

5.  Process  preemption  state 

6.  Process  alarm  state 
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7.  Return  status  code  (if  the  state  changes  as  a  result  of  an  invocation  of  a  Kernel 
primitive) 

8.  Name  of  the  Kernel  primitive  associated  with  the  status  code 

14.1.10.  Monitor  message  attributes 

The  Kernel  shall  provide  the  capability  to  monitor  message  attributes. 

14.1.11.  Disable  monitoring  of  message  attributes 

The  Kernel  shall  provide  the  capability  to  disable  monitoring  message  attributes. 

14.1.12.  Message  attributes  available 

The  message  attributes  that  shall  be  available  for  monitoring  are: 

1 .  Sender’s  process  identifier 

2.  Receiver’s  process  identifier 

3.  Time  message  was  sent  or  received 

4.  Message  tag 

5.  Message  length 

14.1.13.  Monitor  message  contents 

The  Kernel  shall  provide  the  capability  to  monitor  message  contents. 

14.1.14.  Disable  monitoring  of  message  contents 

The  Kernel  shall  provide  the  capability  to  disable  monitoring  message  contents. 

14.1.15.  Monitor  interrupt  attributes 

The  Kernel  shall  provide  the  capability  to  monitor  interrupt  attributes  of  any  declared  interrupt. 

14.1.16.  Specify  interrupts  to  monitor 

The  Kernel  shall  provide  the  capability  to  specify  the  interrupts  on  which  monitoring  is  to  occur. 

14.1.17.  Disable  monitoring  of  interrupt  attributes 

The  Kernel  shall  provide  the  capability  to  disable  monitoring  interrupt  attributes. 

14.1.18.  Interrupt  attributes  available 

The  interrupt  attributes  that  shall  be  available  for  monitoring  are: 

1 .  Kernel  primitives  executed  from  within  interrupt  handlers. 

2.  Return  status  code  of  Kernel  primitives  executed  from  within  interrupt  handlers. 
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14.1.19.  Process  table  available 

The  Kernel  shall  provide  the  capability  to  read  the  Kernel’s  process  table,  which  includes: 

1 .  Process  name 

2.  Process  identifier 

3.  Process  state 

4.  Processor  address 

14.1.20.  Interrupt  table  available 

The  Kernel  shall  provide  the  capability  to  read  the  Kernel’s  interrupt  table,  which  includes: 

1.  Interrupt 

2.  State 

3.  Interrupt  condition 

14.1.21.  No  communication  overhead  incurred 

The  Kernel  shall  not  perform  any  background  Kemel-to-Kernel  communication  to  collect  process, 
message,  or  interrupt  attributes. 

14.1.22.  Monitor  requests  Ignored 

The  Kernel  shall  ignore  all  requests  to  monitor  processes  that  are  unknown,  aborted,  or 
terminated  when  monitoring  is  enabled. 

14.2.  Performance 

14.2.1.  Time  to  define  a  monitoring  activity 

The  definition  of  a  monitoring  activity  shall  take  no  more  than  1 0  ps. 

14.2.2.  Time  to  terminate  a  monitoring  activity 

The  termination  of  a  monitoring  activity  shall  take  no  more  than  5  ps. 

14.2.3.  Time  to  process  a  monitoring  activity 

The  processing  of  a  monitoring  activity  shall  take  no  more  than  5  ps. 

14.2.4.  Tool  predictability 

The  tool  interface  primitives  shall  be  predictable  in  their  use  of  time  and  memory  resources. 

14.2.5.  Time  measured  consistently 

The  Kernel  shall  perform  all  time  measurements  at  a  consistent  point  in  the  Kernel  code. 
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14.2.6.  Data  logged  consistently 

The  Kernel  shall  send  all  logging  messages  at  a  consistent  point  in  the  Kernel  code. 
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III.  Kernel  Primitives 


The  logical  result  of  the  models,  assumptions,  and  restrictions  in  Chapter  4  is  a  Kernel  familiar  to 
most  embedded  systems  software  engineers.  What  this  part  will  define  is  not  new  in  the 
distributed  real-time  processing  world.  However,  it  will  combine  the  known  forms  from  traditional 
(i.e.,  non-Ada)  systems  and  some  of  the  desired  “extensions"  to  Ada  (based,  in  part,  on  the 
thinking  embodied  in  the  [artewg-interface  86]  report)  to  form  a  Kernel  that  can  be  ported  and 
used  by  Ada  applications.  These  extensions  will  appear  to  the  application  program  as  a 
collection  of  Ada  packages  —  reusable  components  —  that,  together  with  certain  application 
programming  conventions,  can  be  combined  with  the  Ada  application  to  execute  in  a  hard 
real-time,  distributed,  embedded  environment. 

The  general  format  for  each  chapter  is: 

•  General  discussion  of  implications  of  our  system  and  process  models  on  the 
primitives. 

•  The  Kernel  primitives,  discussing  their  functionality  and  status  codes. 

•  Where  appropriate,  blocking  primitives  and  their  impacts. 

•  Status  codes  and  their  explanations  (when  needed). 

The  Kernel  communication  model  presents  a  set  of  primitives  to  the  user,  and  implements  those 
primitives  on  an  underlying  set  of  distributed  processors  connected  by  data  paths.  The  model, 
the  implementation,  and  the  intended  mode  of  use,  can  all  be  related  to  the  ISO  Reference  Model 
(See  [Zlmmermann  80]  and  [Tanenbaum  81]),  which  provides  a  conceptual  framework  for 
organizing  the  Kernel  primitives,  as  shown  in  Figure  14-1.  The  ISO  Reference  Model  Identifies 
seven  layers,  named,  from  lowest  to  highest: 

1 .  Physical 

2.  Data  Link 

3.  Network 

4.  Transport 

5.  Session 

6.  Presentation 

7.  Application 

The  target  hardware  provides  Layer  1.  The  Kernel  implements  Layers  2  to  4,  and  therefore 
presents  to  the  user  the  Transport  layer.  The  Kernel  thus  encapsulates  within  itself  the  Data  Link 
and  Network  layers,  rendering  them  invisible  to  the  user.  The  application  code  can  implement 
Layers  5  to  7,  in  part  by  using  other  Kernel  primitives.  The  way  to  do  this  is  described  in  the 
Kernel  User’s  Manual. 
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table,  initialize  master  processor,  and  initialize 
subordinate  processor 


Figure  14-1:  ISO  Model  to  Kernel  Mapping 
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ISO  to  Kernel  Mapping 


Physical  Layer 

The  Physical  iayer  is  represented  by  the  hardware  data  paths,  which  support  the  transmission  of 
a  serial  bitstream  between  processors.  These  hardware  data  paths  are  used  by  the  Kernel  in  a 
packet  switching  mode;  that  is,  a  sequence  of  bits — a  frame — is  sent  at  the  discretion  of  the 
originator,  with  no  implied  reservation  of  resources  or  preservation  of  state  between  frames. 

Data  Link  Layer 

This  is  the  layer  at  which  basic  error  detection  and  recovery  and  flow  control  may  be  provided. 
The  Kernel  uses  a  simple  datagram  model,  in  which  a  frame  is  transmitted  with  no 
acknowledgment,  no  error  correction,  and  no  flow  control.  Minimal  error  detection  is  achieved  by 
using  a  datagram  checksum,  but  any  recovery  is  performed  by  application  code,  i.e.,  above  the 
Transport  layer.  Similarly,  datagram  storage  overflow  is  recognized  and  reported  by  the 
Transport  layer. 

Network  Layer 

In  this  prototype,  the  Kernel  has  a  null  Network  layer.  The  Kernel  assumes  that  point-to-point 
communication  is  avaiiable  between  any  pair  of  nodes  (processors).  Routing  is  accomplished 
trivially  in  the  sender  by  dispatching  a  point-to-point  datagram  directly  to  the  receiver;  no 
alternative  routing  is  provided. 

However,  since  the  abstraction  presented  to  the  user  Is  above  this  layer,  a  real  Network  Layer 
could  subsequently  be  added  without  requiring  any  appiication  code  to  be  changed. 

Transport  Layer 

The  Kernel  builds  the  Transport  layer  by  performing  physical  network  connections  and 
subsequent  logical-to-physical  mappings,  actions  that  together  implement  the  abstraction  of  direct 
process-to-process  communication  by  means  of  messages. 

The  physical  network  is  described  by  a  network  connection  table,  a  copy  of  which  Is  maintained  In 
each  processor.  This  table  is  created  by  the  user  and  communicated  to  the  Kernel  during 
application  initialization.  Once  that  information  is  provided,  the  Kernel  verifies  the  network 
connectivity  and  opens  the  physicai  connections  between  processors. 

Subsequently,  the  logical  processes  and  their  physical  sites  are  communicated  to  the  Kernel. 
The  model  on  which  the  Kernel  is  based  assumes  that  all  processes  are  created  at  initialization 
time,  that  a  process  never  moves,  and  that  a  process  once  dead  is  never  restarted.  The  Kernel 
therefore  computes  the  logical-to-physicai  mapping  once  only  and  never  subsequently  changes  it. 
Attempts  to  communicate  with  dead  processes  are  treated  as  transport  errors. 

The  Transport  layer  also  performs  the  conversions  between  messages  and  the  underlying 
datagrams.  In  this  prototype,  this  is  done  trivially  by  using  one  datagram  per  message  or  per 
acknowledgment  and,  if  necessary,  by  restricting  the  maximum  message  size  accordingly. 
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The  Transport  layer  is  the  layer  visible  to  the  user.  It  supports  unacknowledged  send  operation 
and  end-to-end  acknowledged  send  operations.  All  errors  detected  in  this  or  any  lower  layer  are 
reported  at  this  layer,  in  the  form  of  status  codes  returned  by  the  Kernel  primitives. 

Session  Layer 

This  layer  is  implemented  by  application  code.  Since  it  establishes  logical  connections  between 
processes,  its  presence  is  required,  and  the  user  must  write  specific  code  to  create  it,  as 
explained  in  the  Kernel  User's  Manual.  This  code  is  part  of  the  application  initialization  code;  it 
must  be  present  on  every  processor  and,  in  Ada  terms,  must  be  part  of  the  Main  Unit  on  that 
processor. 

The  model  is  one  of  a  set  of  logical  processes,  each  with  a  user-defined  name  and  each  with  a 
single  message  portior  the  reception  of  messages  from  other  processes. 

The  Kernel  declare  process  primitive  indicates  an  intent  to  create  or  communicate  with  a  given 
named  process.  It  establishes  the  mapping  between  application-level  process  names  and  Kernel 
internal  names. 

The  Kernel  create  process  primitive  creates  the  process,  establishes  its  message  port,  and 
makes  that  port  available  to  the  network.  Thereafter,  one  process  may  communicate  with 
another. 

Presentation  Layer 

In  the  Kernel  model,  the  Presentation  layer  performs  no  transformation  of  data.  Rather,  it 
performs  the  translation  between  Ada  values  —  values  of  user  defined  data  types  —  and 
message  values.  This  is  done  by  application  code,  written  as  prescribed  by  the  Kernel  User's 
Manual.  The  purpose  of  the  Presentation  layer  Is  to  establish  above  the  Transport  layer  the 
strong  typing  of  the  Ada  language,  by  ensuring  that  communicating  processes  pass  only  strongly 
typed  data  and  do  so  by  referencing  a  common  set  of  data  conversion  routines  bound  to  a 
common  Ada  data  type. 

Application  Layer 

This  layer  uses  the  Presentation  layer  for  whatever  purpose  the  code  requires.  The  model  here 
is  of  parallel  independent  threads  of  control  executing  Ada  code,  identifying  each  other  by 
application-level  symbolic  names,  and  communicating  by  passing  values  of  Ada  data  types. 
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15.  Processor  Management 

There  are  two  steps  to  using  the  system  model  shown  in  Figure  4-3.  First,  the  physical  topology 
of  the  system  must  be  defined;  second,  the  system  must  be  initialized.  The  approach  taken  to 
achieve  the  first  step  requires  that  the  application  engineer  first  define  the  network  configuration 
in  a  manner  that  the  Kernel  understands.  This  is  done  using  the  Network  Configuration  Table 
(NCT)  shown  in  Figure  15-1. 


Device 

ID 

Physical 

Address 

Kernel 

Device 

Needed 

To  Run 

Allocated 
Process  ID 

Initialization 

Order 

Initialization 

Complete 

Figure  15-1 :  Sample  Network  Configuration  Table  (NCT) 

This  table  provides  the  minimum  information  needed  by  the  Kernel  to  perform  system  initialization 
and  its  Inter-process  communication  functions.  It  Is  supplied  by  the  application  to  the  Kernel;  it  is 
implementation-  and  hardware-dependent  and  Is  available  to  the  application  for  Implementation  of 
higher  levels  of  network  integrity  (as  discussed  in  the  Kernel  User’s  Manual).  For  each  device 
accessible  over  the  network,  this  table  defines  the  following  information: 

•  Device  ID:  Logical  name  for  the  device. 

•  Physical  address:  Hardware-specific  information  needed  to  access  the  device  over 
the  system  bus. 

•  Kernel  device:  Identifies  those  devices  that  are  able  to  respond  to  messages.  It  is 
possible  to  communicate  with  non-Kemel  devices,  but  they  are  not  expected  to 
participate  in  the  network  initialization  protocol  or  to  understand  the  Kernel’s 
datagram.  Non-Kemel  devices  place  the  burden  of  initialization  and  message 
formatting  upon  the  user.  That  is,  the  Kernel  routes  messages  to  and  receives 
messages  from  non-Kemel  devices,  but  it  is  the  responsibility  of  the  application  to 
format  and  unformat  these  messages. 

•  Needed  to  run:  Identifies  those  devices  that  must  be  available  at  initialization-time  in 
order  for  the  application  to  begin  execution.  This  could  be  used  to  mark  failed  or 
spare  devices  at  startup. 

•  Allocated  process  ID:  Identifies  the  recipient  of  all  messages  that  originate  from  a 
non-Kemel  device.  This  approach  requires  that  the  non-Kemel  device  be  able  to 
route  the  message  to  the  appropriate  node. 

•  Initialization  order:  Identifies  the  order  in  which  the  Kernel  nodes  of  the  network  are 
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to  be  initialized.  The  default,  unless  specifically  overridden,  is  for  the  nodes  to 
initialize  in  the  order  their  entries  occur  in  the  NCT. 

•  Initialization  complete:  Identifies  those  Kernel  nodes  whose  initialization  sequence 
has  successfully  terminated. 

To  achieve  the  second  step,  the  Kernel  has  defined  a  simple  initialization  protocol  (shown  in 
Figure  15-2).  This  protocol  requires  that  one  processor,  called  the  Master,  be  in  charge  of  the 
initialization  process.  All  other  processors  in  the  network  are  subordinate  to  this  processor  during 
the  Kernel’s  initialization  process.  The  Master  is  responsible  for. 

•  Ensuring  the  consistency  of  the  NCT  among  all  the  subordinate  processors. 

•  Issuing  the  "Go"  message  to  all  the  subordinate  processors. 

Some  key  points  to  note  about  this  protocol  are: 

•  The  Master  processor  is  a  single  point-of-failure  in  the  system. 

•  The  Master  assumes  it  has  the  correct  and  complete  version  of  the  Network 
Configuration  Table. 

•  If  any  of  the  following  problems  occurs  at  initialization,  then  the  network  may  fail  to 
become  operational: 

1.  No  Master  processor  declares  itself. 

2.  The  Master  processor  fails  to  initialize  successfully. 

3.  More  than  one  Master  processor  declares  its  presence. 

4.  The  Network  Configuration  Tables  are  found  to  be  inconsistent. 

These  points  can  be  addressed  by  application-specific  fault  tolerant  techniques  (redundant 
hardware,  voting  schemes,  etc.),  which  are  in  the  domain  of  the  application,  not  the  Kernel.  This 
is  discussed  further  in  the  Kernel  User’s  Manual. 


15.1.  Primitives 

15.1.1.  initialize  Master  processor 

This  primitive  Identifies  the  invoker  as  the  processor  that  is  going  to  control  network  initialization. 
It  causes  the  Kernel  to  initiate  the  Master  initialization  protocol  shown  in  part  one  of  Figure  15-2.  It 
requires  a  timeout  that  is  used  to  control  how  long  the  Master  processor  will  wait  for  any  one 
subordinate  to  reply  to  any  initialization  protocol  message.  The  expiration  of  this  timeout  informs 
the  Master  processor  that  network-wide  initialization  has  failed;  K  is  the  responsibility  of  the  Main 
Unit  to  relay  this  Information  to  the  appropriate  parties. 

The  Initialization  protocol  shown  in  Figure  15-2  consists  of  two  phases: 

1 .  Network  phase:  Where  the  Master  processor  Interrogates  each  subordinate  to 
determine  its  view  of  the  network  (embodied  in  the  NCT). 

2.  Commence  processing  phase:  Where  the  Master  processor  tells  each  subordinante 
to  start  normal  processing. 
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Master  Initialization 
Protocol 


The  Master  knows  that  the  physical  topology  of  the 
network  is  consistent  across  processors. 


p  All  processors  know  that  the  physical  topology  of  the  network  is 
^  consistent. 


Figure  15-2:  Network  Initialization  Protocol  (Part  1  of  2) 
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Subordinate  Initialization 
Protocol 


q  Processor  configuration  is  complete; 

°  waiting  for  remaining  processors  to  complete. 

m  All  processors  know  that  the  logical  topology  of  the 
**  network  is  consistent  The  application  is  ready 
to  execute. 


Figure  15-2:  Network  Initialization  Protocol  (Part  2  of  2) 
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Note  that  no  time  information  is  exchanged  during  this  protocol,  if  the  application  requires  time 
synchronization,  the  processor  maintaining  the  system  time  must  explicitly  invoke  the  synchronize 
primitive  (discussed  in  Chapter  21). 

if  this  primitive  faiis  for  any  reason,  no  processor  in  the  network  will  initialize.  This  primitive  can 
give  rise  to  the  foiiowing  status  codes: 

•  OK 

•  initialization  timeout  expired 

•  Processor  failed  to  transmit  NCT 

•  Configuration  tabies  inconsistent 

•  Calling  unit  not  Main  Unit 

•  Multiple  Master  processors  declared 

15.1.2.  Initialize  subordinate  processor 

This  primitive  identifies  the  invoker  as  a  subordinate  (i.e.,  non-Master)  processor  and  begins 
execution  of  the  subordinate  initialization  protocol  shown  in  part  two  of  Figure  15-2.  This  primitive 
has  an  optional  timeout  parameter,  which  may  be  used  to  identify  an  alternate  Master  processor 
in  the  event  the  primary  Master  faiis  to  initialize. 

This  primitive  can  give  rise  to  the  following  status  codes: 

1.  OK 

2.  Calling  unit  not  Main  Unit 

3.  initialization  timeout  expired 

15.1.3.  Start  subordinate  processors 

Deleted  - 1  Juiy  1988.20 

15.1.4.  Create  network  configuration 

This  primitive  creates  the  Network  Configuration  Tabie  shown  in  Figure  15-1.  This  creation  is  a 
static,  compiie-time  operation  performed  by  the  Kernel  user.  A  complete  copy  of  the  NCT  must 
exist  on  every  Kernel  processor  in  the  network. 

This  primitive  always  succeeds. 


“Subsumed  by  Initialize  Master  Processor  (15.1.1). 
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15.2.  Blocking  Primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

Unitialize  Master  processor:  Always  blocks  until  one  of  the  following  conditions 
occurs: 

a.  All  required  processors  in  the  network  have  transmitted  their  NCTs  to  the 
Master,  or 

b.  The  initialization  timeout  expires. 

2.  Initialize  subordinate  processor:  Always  blocks  until  one  of  the  following  conditions 
occurs: 

a.  The  Master  has  requested  the  processor’s  NCT  and  the  subordinate  has 
acknowledged  the  "Go"  message,  or 

b.  The  initialization  timeout  expires. 


15.3.  Status  Codes 

1.  OK:  Normal,  successful  completion. 

2.  Configuration  tables  inconsistent:  A  discrepancy  was  found  between  the  Network 
Configuration  Table  of  a  subordinate  processor  and  the  Network  Configuration 
Table  of  the  Master  Processor. 

3.  Multiple  Master  processors  declared:  Multiple  processors  have  declared 
themselves  network  Master,  an  unresolvable  error  condition. 

4.  Processor  failed  to  transmit  NCT:  Indicates  that  a  processor  has  failed  at  system 
startup  time. 

5.  Processor  failed  to  acknowledge  "Go"  message:  Indicates  that  a  processor  has 
failed  at  system  startup  time. 

6.  Initialization  timeout  expired:  Informs  the  invoker  of  a  serious  network  failure. 

7.  Calling  unit  not  Main  Unit:  Inform  the  invoker  that  this  primitive  may  be  invoked  only 
by  the  Main  Unit  on  a  processor  (and  hence  only  during  initialization). 
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16.  Process  Management 

This  chapter  outlines  the  primitives  provided  to  the  Ada  application  for  creation  and  termination  of 
Kernel  processes.  The  model  used  for  Kernel  process  names  is  this:  to  communicate  with  a 
process,  one  must  know  the  name  of  the  process  either  at  compile  time  or  as  constructed  at 
runtime.  The  name  of  a  process  comes  in  two  forms: 

1. The  logical  name  given  to  the  process  by  the  developer,  encoded  in  Ada  as  a 
character  string,  and 

2.  The  internal  name  given  to  the  process  at  runtime  by  the  Kernel. 

Hereafter,  the  internal  name  of  a  process  is  called  the  process  ID  (PID)  or  process  identifier,  the 
term  process  name  refers  to  the  logical  name  of  the  process.  However,  knowing  the  name  of  a 
process  does  not  guarantee  the  availability  of  the  process  at  runtime.  This  is  one  class  of  faults 
that  the  Kernel  will  be  able  to  detect  and  report. 


16.1.  Primitives 

16.1.1.  Declare  process 

This  primitive  declares  all  Kernel  processes  that  will  execute  locally,  all  remote  Kernel  processes 
with  which  communication  may  occur,  and  any  remote,  non-Kemel  devices  with  which 
communication  will  occur.  This  primitive  may  be  invoked  only  by  the  Main  Unit. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Process  already  exists 

•  Calling  unit  not  Main  Unit 

•  Too  many  processes 

•  Unknown  non-Kemel  device 

16.1.2.  Create  process 

This  primitive  creates  an  independent  thread  of  control.  It  may  be  invoked  only  by  the  Main  Unit 
of  a  processor  to  create  the  Kernel  processes  that  will  share  that  processor.  For  each  process, 
the  application  provides  the  following  information  to  the  Kernel: 

•  Process  attributes:  stack  size,  and  code  address 

•  Scheduling  attributes:  priority  and  preemption21 

•  Communication  attributes:  maximum  message  size,  message  queue  size,  and 
message  queue  overflow  handling 

Once  the  Kernel  has  all  the  process-related  information,  it  constructs  the  execution  environment, 
shown  in  Figure  16-1,  around  the  process.  This  environment  consists  of: 


2,A  process  will  always  be  able  to  modify  its  own  scheduling  information  at  a  later  time. 
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•  Process  stack,  containing: 

•  Stack  plug 

•  Dummy  call  frame 

•  Local  process  variables 

•  Process  control  block,  containing: 

•  Message  queue 

•  Schedule  attributes 

•  Process  code 

•  Context  save  area 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  process  address 

•  Illegal  process  identifier 

•  Process  already  exists 

•  Too  many  processes 

•  Calling  unit  not  Main  Unit 

•  Illegal  communication  attribute 

•  Illegal  scheduling  attribute 

•  Insufficient  process  space  available 

16.1.3.  Initialization  complete 

This  primitive  asserts  that  the  declaration  and  creation  of  all  processes  on  this  processor  is  now 
complete.  It  is  invoked  by  the  Main  Unit  of  that  processor  after  all  processes  have  been  declared 
and/or  created.  This  primitive  effectively  tells  the  Kernel  “I'm  alive  and  ready  to  roll!"  —  the 
application  code  is  ready  to  run  —  and  the  Kernel  relays  this  information  to  all  the  other  Kernels 
in  the  network.  This  primitive  takes  an  optional  timeout  parameter  to  detect  processor  failure 
after  network  initialization. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Initialization  timeout  expired 

•  Remote  process  undefined 

•  Process  already  exists 
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Figure  16-1:  Process  Execution  Environment 
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16.1.4.  Allocate  device 

This  primitive  assigns  a  specific  process  to  be  the  recipient  of  all  messages  originating  from  a 
specific  non-Kernel  device  although  any  process  can  send  a  message  to  a  non-Kernel  device.22 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Replacing  previous  allocation 

•  Unknown  non-Kernel  device 

16.1.5.  Die 

This  primitive  terminates  the  calling  process  (self-termination  only,  used  for  normal  successful 
completion)  and  may  be  invoked  by  any  process  at  any  time.  Since  processes  have  no 
dependents,  each  one  terminates  individually.  Messages  pending  when  a  process  terminates  are 
discarded,  as  are  messages  that  arrive  after  a  process  has  terminated.  Note  that  only  Kernel 
processes  may  be  terminated  by  this  primitive.  Terminating  a  non-Kernel  process  is  the  user's 
responsibility. 

This  primitive  can  give  rise  to  the  following  status  code: 

•  Illegal  process  identifier 

16.1.6.  Kill 

This  primitive  aborts  the  specified  process  and  may  be  invoked  by  any  process  at  any  time.  This 
can  be  applied  to  any  named  process,  including  the  calling  process.  This  is  an  "abnormal" 
termination,  and  causes  an  immediate  action  by  the  Kernel.  If  the  aborted  process  is  remote,  the 
actual  abortion  may  occur  after  return  from  this  primitive.  Messages  pending  when  a  process  is 
aborted  are  discarded,  as  are  messages  that  arrive  after  a  process  has  aborted. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  process  identifier 

16.1.7.  Who  ami 

This  primitive  allows  a  process  to  obtain  its  own  process  identifier  and  may  be  invoked  by  any 
process  at  any  time. 

This  primitive  always  succeeds. 


22Of  course,  it  must  be  property  formatted  for  the  device  by  the  application. 
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1 6.1 .8.  Name  of 

This  primitive  allows  a  process  to  obtain  the  logical  name  of  a  process  for  which  it  has  a  process 
ID.  It  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  process  identifier 

•  No  such  process 


16.2.  Blocking  Primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

1.  Initialization  complete:  Always  blocks  until  one  of  the  following  conditions  occurs: 

a.  All  needed  process  creation  acknowledgments  are  received,  or 

b.  The  initialization  timeout  expires. 

16.3.  Status  Codes 

1.  OK. 

2.  Replacing  previous  allocation:  The  current  process  allocated  to  the  device  is 
replaced  by  the  invoking  process. 

3.  No  such  device  exists:  The  requested  non-Kemel  device  is  not  known  at  the 
requesting  site. 

4.  Illegal  process  address:  The  code  address  of  the  process  is  not  a  valid  Ada 
address. 

5.  Illegal  process  identifier:  A  nonexistent  process  identifier  was  used. 

6.  Illegal  communication  attribute:  At  least  one  of  the  communication  attributes 
specified  at  process  creation-time  is  invalid. 

7.  Illegal  scheduling  attribute:  At  least  one  of  the  scheduling  attributes  specified  at 
process  creation-time  is  invalid. 

8.  Remote  process  undefined:  A  process  was  declared,  but  no  processor  in  the 
network  created  the  process. 

9.  Calling  unit  not  Main  Unit. 

10.  Too  many  processes:  Declaration  exceeded  maximum  number  of  processes 
allowed. 

11.  Unknown  non-Kemel  device:  No  such  device  identified  in  the  NCT. 

12.  Process  already  exists. 

13.  Too  many  processes. 

14.  Insufficient  process  space  available:  Insufficient  memory  exists  for  the  creation  of 
another  process. 
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15.  Initialization  timeout  expired. 
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17.  Semaphore  Management 

The  Kernel  provides  the  traditional  Boolean  ("Dykstra")  semaphore  facility,  slightly  revised  to  be 
consistent  with  the  overall  philosophy  of  the  Kernel  primitives. 

A  semaphore  is  an  abstract  data  type.  Objects  of  this  type  may  be  declared  anywhere,  but  since 
semaphores  are  used  to  build  process  synchronization  systems,  they  are  clearly  best  declared  in 
the  Main  Unit  of  a  processor.  A  semaphore  is  visible  only  on  the  processor  on  which  it  is 
declared,  and  therefore  can  be  used  only  by  processes  local  to  that  processor,  for  example  for 
application-level  control  of  shared  memory. 

At  any  time,  a  semaphore  is  in  one  of  two  states: 

•  FREE:  The  semaphore  is  free,  or 

•  CLAIMED(N):  The  semaphore  is  claimed,  and  N  processes  are  awaiting  its  release. 

These  processes  are  blocked  on  a  FIFO  queue  associated  with  the  semaphore. 


17.1.  Primitives 

17.1.1.  Declare  Semaphore 

A  semaphore  is  declared  by  a  normal  Ada  declaration.  Its  initial  state  is  FREE. 

This  primitive  always  succeeds. 

17.1.2.  Claim  Semaphore 

This  primitive  attempts  to  claim  the  semaphore.  If  the  semaphore  was  free,  the  primitive 
succeeds,  the  semaphore  state  changes  to  CLAIMED(O),  and  the  invoking  process  continues. 

If  the  semaphore  was  CLAIMED(N),  then  the  invoking  process  blocks.  The  state  changes  to 
CLAIMED(N+1),  and  the  process  is  appended  to  the  semaphore  queue.  The  call  can  optionally 
specify  a  timeout  time  or  duration,  and  a  resumption  priority. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  semaphore 

•  Illegal  time 

•  Illegal  duration 

•  Illegal  resumption  priority 

•  Blocking  prohibited  in  this  context 

•  Claim  timed  out 
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17.1.3.  Release  Semaphore 

This  primitive  attempts  to  release  a  semaphore  previously  claimed.  The  state  necessarily  must 
be  CLAIMED(N).  If  N=0,  no  other  process  is  waiting,  and  the  semaphore  becomes  FREE. 
Otherwise,  the  state  becomes  CLAIMED(N-I),  and  the  process  at  the  head  of  the  semaphore 
queue  is  given  the  semaphore  and  becomes  suspended. 

Note  that  a  RELEASE  cannot  block,  but  may  cause  the  invoking  process  to  be  preempted  if  the 
process  at  the  head  of  the  queue  has  a  higher  priority. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  semaphore 

•  Semaphore  not  claimed  by  invoker 


17.2.  Blocking  primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

1.  Claim:  Blocks  only  when  the  state  of  the  requested  semaphore  is  CLAIMED(N).  It 
will  unblock  when  one  of  the  following  conditions  occurs: 

a.  The  semaphore  is  released  and  the  invoking  process  is  at  the  head  of  the 
wait  queue,  or 

b.  The  claim  timeout  expires. 

17.3.  Status  Codes 

1.  OK. 

2.  Illegal  semaphore:  Attempting  to  use  an  undeclared  semaphore 

3.  Illegal  time:  Illegal  timeout  specified. 

4.  Illegal  duration:  Illegal  timeout  specified. 

5.  Illegal  resumption  priority. 

6.  Blocking  prohibited  in  this  context. 

7.  Claim  timed  out:  Operation  unblocked  due  to  timeout  expiration. 

8.  Semaphore  not  claimed  by  invoker:  Attempt  to  release  a  semaphore  that  has  not 
previously  been  claimed  by  the  invoker. 
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18.  Schedule  Management 

This  chapter  outlines  the  basic  scheduling  mechanisms  to  be  provided  by  the  Kernel.  The 
scheduling  paradigm  used  by  the  Kernel  is  a  simple,  prioritized,  event-driven  model  that  permits 
the  construction  of  preemptive,  cyclic,  and  non-cyclic  processes.  To  achieve  this,  there  are  four 
types  of  events  in  this  model: 

1.  Receipt  of  a  message  (synchronous  event). 

2.  Receipt  of  a  message  acknowledgment  (asynchronous  event). 

3.  Expiration  of  a  primitive  timeout  (asynchronous  event). 

4.  Expiration  of  an  alarm  (asynchronous  event). 

The  scheduling  primitives  are  discussed  below,  and  the  alarm  primitives  are  discussed  in  Chapter 
22.  This  paradigm  allows  the  user  to  create: 

•  A  non-cyclic  process  that  executes  until  preempted  by  a  higher-priority  process. 

•  A  set  of  non-cyclic  processes  that  execute  in  a  round-robin,  timesliced  manner. 

•  An  event-driven  process  that  blocks  when  trying  to  receive  a  message.  It  is  resumed 
from  the  point  of  suspension,  when  it  is  able  to  proceed  and  when  the  priority  admits. 

•  An  event-driven  process  that  blocks  itself  for  a  specified  period  of  time  (or 
equivalently,  until  a  specific  time)  and  is  resumed  at  a  specific  priority  (this  allows  a 
"hard"  delay  to  be  implemented). 

•  A  cyclic  process  that  continuously  executes  a  body  of  code  (and  that  can  detect 
frame  overrun). 

To  support  these  paradigms,  the  following  set  of  scheduling  attributes  Is  defined: 

•  Priority: 

•  Every  process  has  a  priority. 

•  Priorities  are  relative  within  one  processor. 

•  Priorities  are  incommeasurable  across  processors. 

•  A  process  may  change  its  priority  dynamically. 

•  Priorities  are  strict  and  pre-emptive;  higher-priority  processes  always  shut  out 
lower-priority  processes. 

•  Blocking  primitives  allow  the  caller  to  specify  a  resumption  priority,  which  may 
be  different  from  the  priority  at  the  point  of  invocation.  The  resumption  priority 
is  the  priority  of  the  process  when  it  unblocks. 

•  Timeslice: 

•  The  maximum  length  of  time  a  process  may  run  before  another  process  of  the 
same  priority  is  allowed  to  run. 

•  A  property  of  a  set  of  processes  on  the  same  processor  and  all  of  the  same 
priority. 

•  Timeslicing  cannot  override  priority;  it  applies  only  among  processes  of  equal 
priority. 
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•  Any  process  may  enable  or  disable  timeslicing  for  the  entire  processor. 

•  Any  process  may  set  the  timeslice  quantum. 

•  A  process  may  allow  (or  disallow)  itself  to  be  sliced  by  setting  its  preemption 
status  (if  preemptable,  the  process  may  be  timesliced;  if  not  preemptable,  the 
process  may  not  be  timesliced  by  another  process  of  the  same  priority). 

Given  this  scheduling  regime,  a  process  is  always  in  one  of  four  states: 

•  Running-.  A  running  process  is  executing  on  its  processor,  and  it  continues  to  run 
until  something  happens.  If  interrupts  are  enabled,  they  occur  transparently  unless 
they  cause  a  change  of  process  state.  A  running  process  ceases  to  run  when  it: 
dies,  invokes  a  blocking  Kernel  primitive,  is  timesliced,  is  killed  by  another  process, 
or  is  preempted  by  a  higher-priority  process.  The  first  three  are  voluntary  actions  on 
the  part  of  the  process,  while  the  last  two  are  actions  performed  by  the  Kernel. 

•  Dead-.  A  dead  process  is  unable  to  run  again.  A  process  dies  in  one  of  five  ways:  by 
completing  execution,  an  unhandled  exception,  an  unrecoverable  error,  by  killing 
itself,  or  by  being  killed  by  another  process.  Processes  are  not  expected  to  die,  and 
any  subsequent  attempts  to  interact  with  a  dead  process  result  in  errors. 

•  Blocked .  A  blocked  process  is  unable  to  run.  A  process  may  only  become  blocked 
as  a  result  of  its  own  actions.  These  blocking  actions  are  waiting  for:  the  arrival  of  a 
message,  the  arrival  of  a  message  acknowledgment,  a  specific  duration,  a  specific 
time,  or  the  availability  of  a  semaphore.  A  process  becomes  unblocked  when  the 
blocking  event  occurs  (at  which  time  the  process  transitions  to  the  suspended  state). 

An  unblocked  process  does  not  immediately  resume  execution;  it  resumes  execution 
only  when  the  scheduler  so  decides.  But,  the  process  can  affect  this  decision  by 
specifying  a  resumption  priority  in  the  primitive  invocation. 

•  Suspended:  A  suspended  process  is  able  to  run,  but  cannot  run  because  a  process 
of  higher  or  equal  priority  is  running.  A  process  may  be  resumed  when  the  running 
process  blocks,  lowers  its  own  priority,  or  is  timesliced. 

These  states  and  the  transitions  between  them  are  shown  in  Figure  18-1. 

For  instance,  a  running  process  becomes  blocked  by  trying  to  receive  when  no  message  is 
pending.  It  becomes  unblocked  (but  suspended)  when  the  message  arrives.  It  becomes  running 
when  its  priority  permits.  A  running  process  can  also  call  wait,  to  wait  itself  at  any  time.  A 
blocked  process  becomes  suspended  and  thus  ready  to  run  when  its  delay  expires.  Further,  a 
running  process  may  be  preempted,  that  is,  forcibly  suspended  against  its  will,  to  allow  a 
higher-priority  process  to  resume  or  to  be  timesliced. 


18.1.  Primitives 

18.1.1.  Set  process  preemption 

This  primitive  changes  the  preemption  state  of  the  calling  process.  A  process  may  set  only  its 
own  preemption  state.  This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  always  succeeds. 
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Figure  18-1 :  Process  States 

18.1.2.  Get  process  preemption 

This  primitive  queries  the  current  value  of  the  preemption  state  of  the  calling  process.  A  process 
may  query  only  its  own  preemption  state.  This  primitive  may  be  invoked  by  any  process  at  any 
time. 

This  primitive  always  succeeds. 

18.1.3.  Set  process  priority 

This  primitive  changes  the  priority  of  the  calling  process.  A  Kernel  process  may  set  only  its  own 
priority.  This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  always  succeeds. 

18.1.4.  Get  process  priority 

This  primitive  queries  the  current  value  of  the  priority  of  the  calling  process.  A  process  may  query 
only  its  own  priority.  This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  always  succeeds. 
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18.1.5.  Wait 

This  primitive  allows  the  invoker  to  suspend  its  own  execution: 

•  Until  a  specified  time,  or 

•  For  a  specified  duration. 

An  optional  resumption  priority  may  also  be  specified.  This  primitive  may  be  invoked  by  any 
process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  priority 

•  Illegal  duration 

•  Illegal  time 

18.1.6.  Settimeslice 

This  primitive  sets  the  timeslice  quantum  for  the  processor. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  timeslice 

18.1.7.  Enable  timeslicing 

This  primitive  enables  the  Kernel  to  perform  round-robin,  timeslice  scheduling  among  processes 
of  equal  priority. 

This  primitive  always  succeeds. 

18.1.8.  Disable  timeslicing 

This  primitive  disables  round-robin,  timeslice  scheduling.  After  execution  of  this  primitive, 
scheduling  is  priority-based  preemption. 

This  primitive  always  succeeds. 


18.2.  Blocking  primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

1.  Wait:  Always  blocks  until  the  delay  (i.e.,  the  specified  absolute  or  elapsed  time) 
expires. 
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18.3.  Status  Codes 


1.  OK 

2.  Illegal  duration 

3.  Illegal  time 

4.  Illegal  time  slice 
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19.  Communication  Management 

This  chapter  outlines  the  primitives  provided  tor  communication  between  Kernel  processes  (see 
Chapter  15  for  details  about  how  the  communication  model  ties  into  the  network  model).  The 
communication  model  is  based  on  the  following  premises: 

•  All  communication  is  point-to-point. 

•  A  sender  must  specify  the  recipient. 

•  A  recipient  gets  all  messages  and  is  told  the  sender  of  each. 

•  A  recipient  cannot  ask  to  receive  only  from  specific  senders. 

•  Messages  do  not  have  priorities. 

The  purpose  of  a  message  is  to  convey  information  between  processes.  To  the  Kernel,  a 
message  is  just  a  sequence  of  uninterpreted  bits.  The  Kernel  provides  the  untyped  primitives;  the 
users  may  build  above  them  whatever  application-specific  functionality  is  needed.  Note  that  any 
two  (or  more)  communicating  processes  are  free  to  define  a  common  package  containing  their 
interface  message  types.  Communication  between  processes  on  a  single  processor  will  be 
optimized. 

Figure  19-1  illustrates  this  communication  model.  In  this  figure,  process  Merlin  on  Processor  a 
sends  a  message  to  process  Vivian  on  Processor  b.  This  is  accomplished  by  Merlin's  informing 
the  Kernel  of  the  message  content  and  the  logical  destination  of  the  message  (i.e.,  Vivian).  The 
Kernel  on  Processor  a  takes  this  message,  formats  the  datagram  to  hold  the  message,  and 
transmits  the  datagram  over  the  network  to  Processor  b,  where  it  knows  Vivian  resides.  When 
the  message  arrives  at  Processor  b,  the  Kernel  there  rebuilds  the  message  from  the  datagram 
and  queues  it  for  Vivian  until  Vivian  requests  the  next  message.  If  Merlin  had  wanted 
acknowledgment  of  message  receipt  by  Vivian,  the  Kernel  on  Processor  b  would  have  formatted 
an  acknowledgment  datagram  and  sent  it  back  to  Processor  a  after  Vivian  had  asked  for  (and 
received)  the  message. 


19.1.  Primitives 

19.1.1.  Send  message 

This  primitive  is  used  to  send  a  message  from  one  process  to  another,  without  waiting  for 
acknowledgment  of  message  receipt.  This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Receiver  never  existed 

•  Network  failure 
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Figure  1 9-1 :  Datagram  Network  Model 
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19.1.2.  Send  message  and  wait 

This  primitive  is  used  to  send  a  message  from  one  process  to  another;  the  sender  blocks  while 
waiting  for  acknowledgment  of  message  receipt  by  the  receiving  process.  This  primitive  may  be 
invoked  by  any  process  at  any  time.  However,  it  may  not  be  invoked  by  an  interrupt  handler.  An 
optional  timeout  may  be  specified.  If  a  timeout  is  specified,  the  Kernel  performs  a  remote 
timeout;  that  is,  the  timeout  is  bundled  with  the  message  and  executed  by  the  Kernel  of  the 
receiving  process.  If  the  timeout  expires,  the  message  is  purged  from  the  receiver's  message 
queue  and  the  invoking  process  is  notified.  The  Kernel  rejects  all  calls  where  the  recipient  is  the 
sender. 

This  primitive  can  give  rise  to  the  following  status  codes; 

•  OK 

•  Message  timed  out 

•  Receiver  never  existed 

•  Receiver’s  queue  full 

•  Message  not  received 

•  Receiver  dead 

•  Blocking  prohibited  in  this  context 

•  Receiver  is  sender 

•  Network  failure 

1 9.1 .3.  Receive  message 

This  primitive  is  used  to  receive  a  message  from  another  process.  This  primitive  may  be  invoked 
by  any  process  at  any  time.  If  this  primitive  is  invoked  by  an  interrupt  handler  or  with  a 
zero-duration  timeout,  it  will  not  block,  but  will  return  immediately  with  a  status  code  should  no 
message  be  available.  The  Kernel  will  automatically  perform  any  required  acknowledgments.  An 
optional  timeout  may  be  specified.  If  a  timeout  is  specified,  the  Kernel  performs  a  local  timeout.  If 
the  timeout  expires,  the  invoking  process  is  notified. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Message  timed  out 

•  No  message  available 

•  Messages  lost 
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19.2.  Blocking  Primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

1 .  Send  message  and  wait:  Always  blocks  until  one  of  the  following  conditions  occurs: 

a.  The  receiving  process  has  requested  and  received  the  message,  or 

b.  The  message  timeout  expires. 

2.  Receive  message:  Blocks  only  if  there  is  no  message  currently  available  for  the 
process.  If  no  message  is  available,  then  it  blocks  until  one  of  the  following 
conditions  occurs: 

a.  A  message  has  arrived  for  the  process,  or 

b.  The  timeout  expires. 


19.3.  Status  Codes 

1.  OK 

2.  Message  timed  out:  Timeout  expired  without  operation  completing. 

3.  Message  not  received:  The  message  was  discarded  from  the  receiver's  message 
queue. 

4.  Receiver  dead:  Destination  process  has  terminated  or  been  aborted. 

5  Blocking  prohibited  in  this  context:  Occurs  when  the  invoker  has  used  a  primitive 
that  is  about  to  block  further  process  execution,  but  the  process  is  in  a  state  where 
blocking  is  prohibited  (i.e.,  an  Interrupt  handler). 

6.  No  message  available:  Occurs  in  situations  where  blocking  the  invoking  process  is 
prohibited  or  a  zero  timeout  is  specified. 

7.  Receiver  never  existed. 

8.  Receiver  queue  full:  A  negative  acknowledgment  when  there  is  insufficient  space  in 
the  receiver’s  message  queue  for  the  message. 

9.  Receiver  is  sender:  A  process  can  not  perform  an  acknowledged  send  with  itself. 

10.  Messages  lost:  Occurs  when  the  Kernel’s  message  buffer  overflows  and  messages 
are  discarded. 

1 1 .  Network  failure:  A  network  problem  prevented  transmission  of  the  message. 
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20.  Interrupt  Management 

This  section  outlines  the  interrupt  control  primitives  provided  by  the  Kernel.  There  are  two  parts 
to  the  Kernel’s  view  of  interrupts:  interrupts  themselves  and  interrupt  handlers.  The  interrupt 
model  used  by  the  Kernel  is  based  on  the  following  premises: 

•  There  are  devices  that  can  interrupt  the  processor. 

•  There  are  three  classes  of  interrupts: 

1.  Those  reserved  by  the  Ada  runtime  environment  (divide -by-zero, 
floating-point  overflow,  etc.). 

2.  Those  reserved  by  the  Kernel  (such  as  the  clock  interrupt). 

3.  Those  available  to  the  user  (everything  not  in  1  and  2  above). 

All  the  primitives  described  below  apply  only  to  the  third  class  of  interrupts. 

•  The  device  interrupt  may  be  either  enabled  or  disabled.  If  the  interrupt  is  disabled, 
the  device  cannot  interrupt,  regardless  of  how  badly  it  might  want  to. 

•  The  Kernel  does  not  queue  interrupts  nor  will  it  hide  hardware-level  interrupt 
properties,  such  as  queueing  of  interrupts,  interrupt  priorities,  or  non-maskable 
interrupts. 

•  Interrupts  are  events  local  to  a  processor  and  cannot  be  directly  handled  or  bound  by 
processes  running  on  a  different  processor. 

The  model  used  for  interrupt  handlers  is: 

•  An  interrupt  handler  is  an  Ada  procedure  with  no  parameters  or  some  other  code 
following  the  same  procedure-call  conventions. 

•  Interrupt  handler  code  can  access  procedure  local  or  processor  global  memory. 

•  Interrupt  handler  code  has  access  to  all  the  Kernel  primitives:  the  only  restriction  is 
that  a  handler  will  not  be  allowed  to  block  its  own  execution. 

•  If  an  interrupt  is  enabled  and  a  handler  is  bound,  then  the  occurrence  of  the  interrupt 
transfers  control  to  the  bound  handler,  which  is  code  the  user  has  supplied. 

The  primitives  that  implement  these  two  models  are  discussed  below. 


20.1.  Primitives 

20.1.1.  Enable 

This  primitive  allows  the  specified  interrupt  to  occur.  No  interrupt  can  be  enabled  via  the  Kernel 
unless  the  Kernel  has  bound  a  handler  for  that  interrupt.  This  implies  that  there  may  be  handlers 
bound  outside  the  knowledge  of  the  Kernel.  This  is  legitimate,  since  the  Kernel  is  only 
responsible  for  those  handlers  that  it  binds.  This  primitive  may  be  invoked  by  any  process  at  any 
time  (Including  the  Main  Unit). 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 
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•  Illegal  interrupt  name 

•  No  interrupt  handler  bound 

20.1.2.  Disable 

This  primitive  prohibits  the  specified  interrupt  from  occurring.  This  primitive  may  be  invoked  by 
any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  interrupt  name 

20.1 .3.  Enabled 

This  primitive  queries  the  status  of  the  specified  interrupt,  i.e.,  whether  it  is  enabled  or  disabled. 
This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  interrupt  name 

20.1.4.  Simulate  interrupt 

This  primitive  simulates  the  occurrence  of  a  specified  interrupt  in  software.  An  interrupt  handler 
must  be  bound  to  the  specified  interrupt  for  this  primitive  to  have  an  effect.  This  primitive  may  be 
invoked  by  any  process  at  any  time.  This  primitive  returns  only  after  the  interrupt  handler  has 
completed  its  processing. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Illegal  interrupt  name 

•  No  interrupt  handler  bound 

20.1.5.  Bind  interrupt  handler 

This  primitive  associates  the  specified  interrupt  with  the  Ada  procedure23  identified  as  the 
interrupt  handler.  This  primitive  may  be  invoked  by  any  process  at  any  time  (including  the  Main 
Unit).  Any  attempt  to  bind  a  different  interrupt  handler  to  a  bound  interrupt  results  in  the  old 
handler  being  replaced.  Invocation  of  this  primitive  causes  the  Kernel  to  construct  an  execution 
environment  for  the  handler,  as  shown  in  Figure  20-1.  The  environment  consists  of: 

•  Local  stack,  containing: 

•  Stack  plug 

•  Dummy  call  frame 


^Or  an  equivalent  procedure  in  another  language. 
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•  Local  procedure  variables 
•  Interrupt  table  entry,  containing: 

•  Handler  stack 

•  Handler  code 

•  Interrupt  Vector  address 


Figure  20-1 :  Interrupt  Handler  Execution  Environment 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Replacing  previous  interrupt  handler 

•  Illegal  interrupt  name 

•  Reserved  interrupt 

•  Illegal  interrupt  handler  address 
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20.2.  Blocking  Primitives 

None. 


20.3.  Status  Codes 

1.  OK. 

2.  Replacing  previous  interrupt  handler. 

3.  No  interrupt  handler  bound:  An  interrupt  cannot  be  enabled  for  which  no  handler 
has  been  defined  (i.e.,  bound). 

4.  Illegal  interrupt  name. 

5  Reserved  interrupt. 

6  Illegal  interrupt  handler  address:  The  address  specified  for  the  interrupt  handler 
code  is  not  a  legal  Ada  address. 
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21.  Time  Management 

The  concept  of  time  permeates  the  entire  Kernel.  Many  of  the  Kernel  concepts  and  primitives 
rely  on  time,  specifically: 

•  Network  management  uses  time  for  initial  clock  synchronization  and  for  timeout 
parameters  in  the  primitives:  initialize  master,  initialize  subordinate,  and  start 
subordinates. 

•  Process  management  requires  time  for  setting  up  the  initial  process  scheduling 
information,  in  the  create  process  primitive,  and  for  a  timeout  parameter,  in 
initialization  complete  primitive. 

•  Schedule  management  uses  time  for  round-robin,  timeslice  scheduling  and  for 
delays  via  the  wait  primitive. 

•  Communication  management  requires  time  for  timeout  operations  in  receive 
message  and  send  message  and  wait  primitives. 

•  Alarm  management  uses  time  for  setting  alarms  via  the  set  alarm  primitive. 

To  support  these  primitives,  the  Kernel  contains  facilities  for  time  management,  both  for  its  own 
use  and  to  make  available  to  the  application  code.  In  all  cases,  two  forms  of  delay  are  available 
to  the  application: 

•  Delay  For:  This  computes  the  delay  as  elapsed  time  from  the  moment  the  primitive  is 
called.  The  delay  is  therefore  a  value  of  the  Ada  type  DURATION. 

•  Delay  Until:  This  delays  until  a  specified  time  of  resumption.  The  delay  is  therefore  a 
value  of  the  Ada  type  TIME. 

The  rationale  for  the  two  types  of  delay  is  that  they  express  fundamentally  different  concepts.  For 
example,  if  a  certain  action  should  be  performed  daily  at  midnight,  it  is  not  correct  to  perform  the 
action  "every  24  hours,"  since  successive  midnights  are  not  always  24  hours  apart.  Similarly,  if 
an  action  should  be  performed  every  5  minutes,  it  is  not  correct  to  schedule  three  such  actions  for 
0155,  0200,  and  0205,  since  65  minutes  might  elapse  between  the  second  and  third  (i.e.,  the 
clock  might  have  been  reset). 

The  application  programmer  must  be  able  to  choose  the  type  of  delay  needed.  Note  also  that 
resetting  the  system  time  affects  the  two  types  of  delay  differently. 

In  the  current  design,  the  assumption  is  made  that  it  is  feasible  for  all  the  target  processors  to  use 
a  common  time  base  and  to  record  the  passage  of  time  at  the  same  uniform  rate.  It  must  be 
recognized  that  there  are  some  real-time  applications  for  which  this  assumption  is  unrealistic, 
since  the  processors  will  be  distributed  across  several  different  inertial  frames  of  reference,  but  it 
will  serve  for  this  prototype. 

It  is  necessary  therefore  to  describe  the  local  representation  of  time  and  the  clock  synchronization 
mechanisms. 
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Representation  of  Time 

At  any  moment,  on  any  processor,  the  current  time  is  given  by  a  combination  of  three  values 

1.  Elapsed.  The  elapsed  time  is  the  number  of  ticks  since  the  end  of  the  application 
initialization  process. 

2.  Epoch.  The  epoch  is  a  value  representing  the  moment  at  which  the  processors 
began  to  compute  elapsed  time. 

3.  Base.  The  base  is  the  calendar  date  corresponding  to  an  epoch  of  zero,  i.e.,  the 
base  of  the  representation  of  time.  Julian  Day  1  (started  at  1200  on  1  January 
4713BCE)  has  been  chosen.24 

The  representation  chosen  for  both  epoch  and  elapsed  will  be  fine  enough  to  allow  accurate 
measurement  and  large  enough  to  allow  code  to  run  for  a  very  long  time.  Thus  the  current  time 
of  day  =  Base  +  Epoch  +  Elapsed. 

Time  is  set  initially  on  some  processor  in  the  network  by  the  application.  This  is  done  either  by 
hand,  during  operator  dialogue,  or  by  reading  a  continuously  running  hardware  device.  The 
processors  may  then  synchronize  system  time  by  having  this  processor  use  the  synchronize 
primitive  discussed  below.  This  gives  the  application  complete  control  over  when  to  synchronize 
system  time.  Once  the  clocks  are  synchronized,  the  Kernel  does  not  attempt  to  maintain  the 
synchronization.  The  processors  resynchronize  only  as  a  result  of  deliberate  action  by  application 
code. 

Three  forms  of  resynchronization  are  supported: 

1  The  elapsed  time  for  any  processor  can  be  changed  by  an  explicit  command.  This 
is  to  be  used  when  one  processor's  time  computation  has  gone  awry.  It  will  have 
the  effect  of  changing  pending  delays  of  either  kind,  since  increasing  the  number  of 
elapsed  ticks  will  make  the  machine  think  both  that  it  has  been  running  longer  and 
that  it  is  later  in  the  day. 

2.  The  epoch  time  of  any  processor  may  be  changed.  This  Is  to  be  used  if  it  is 
discovered  that  the  original  time  setting  was  wrong.  It  will  have  the  effect  of 
changing  any  pending  delay-until  actions,  since  increasing  the  epoch  will  make  the 
machine  think  it  is  later  in  the  day,  but  will  not  change  how  long  it  thinks  it  has  been 
running. 

3.  The  Kernel  provides  a  primitive  that  explicitly  synchronizes  all  the  clocks  in  the 
network,  as  defined  in  Section  21.1.6. 


24Thus,  1  January  88  is  JD  2447162. 
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21.1.  Primitives 


21.1.1.  Package  calendar 

The  Ada  package  calendar  will  be  supported.  As  far  as  possible,  the  existing  vendor-supplied, 
package  will  be  used.  However,  some  modification  will  be  necessary  because  the  Kernel  will  be 
in  control  of  the  hardware  clock.  Also,  the  Kernel  does  not  use  the  package  Calendar  internally, 
so  applications  are  not  required  to  include  it  in  the  load  modules. 

21.1.2.  Time  constants 

The  Kernel  will  define  the  constants: 

•  TICK:  Smallest  resolvable  interval  of  time. 

•  SLICE:  Smallest  schedulable  interval  of  time. 

SLICE  is  defined  as  an  integer  multiple  of  TICK.  The  Kernel  will  maintain  durations  internally 
accurate  to  the  TICK,  but  all  time  values  that  imply  scheduling  action,  such  as  delay  times,  are 
truncated  to  the  nearest  SLICE.  The  definition  of  TICK  and  SLICE  are  local  to  a  processor,  and 
no  relationship  between  these  definitions  is  assumed  or  required  across  the  processors  in  the 
network. 

21.1.3.  Adjust  elapsed  time 

This  primitive  allows  the  application  to  increment  or  decrement  the  current  local  elapsed  time  by  a 
specified  number  of  clock  ticks.  This  primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  one  of  the  following  status  codes: 

1.  OK. 

2.  Change  would  reset  elapsed  time  to  a  negative  value. 

3.  Change  would  cause  elapsed  time  to  overflow. 

21.1.4.  Adjust  epoch  time 

This  primitive  allows  the  application  to  reset  the  epoch  time  of  the  local  processor  clock.  This 
primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  one  of  the  following  status  codes: 

1.  OK. 

2.  OK,  but  requested  time  has  already  passed. 

3.  Change  would  reset  epoch  time  to  a  negative  value. 

4.  Change  would  cause  epoch  time  to  overflow. 
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21.1.5.  Read  clock 

This  primitive  reads  the  local  processor  clock  and  returns  the  elapsed  time  in  ticks. 

This  primitive  always  succeeds. 

21.1 .6.  Synchronize 

This  primitive  forces  all  local  processor  clocks  on  Kernel  devices  to  synchronize  time  with  the 
local  clock  on  the  invoking  processor.  This  primitive  takes  an  optional  timeout  parameter.  This 
primitive  may  be  invoked  by  any  process  at  any  time. 

The  post-conditions  of  this  primitive  are: 

1  If  it  completes  successfully,  all  clocks  are  synchronized. 

2  If  it  terminates  with  an  error,  the  exact  state  of  network  time  is  not  known. 

This  primitive  can  give  rise  to  one  of  the  following  status  codes: 

1  Network  failure. 

2.  Multiple  synchronization  failure. 

3.  Synchronization  timeout. 

21.2.  Blocking  Primitives 

This  section  lists  which  of  the  primitives  described  above  may  block  the  invoking  process  and  the 
conditions  under  which  they  will  block: 

1.  Synchronize:  This  primitive  always  blocks  the  invoker  until: 

a.  All  Kernel  clocks  are  synchronized, 

b.  An  error  condition  is  detected,  or 

c.  The  timeout  expires. 

21 .3.  Status  Codes 

1 .  OK. 

2.  OK,  but  requested  time  has  already  passed. 

3.  Change  would  reset  elapsed  time  to  a  negative  value. 

4.  Change  would  reset  epoch  time  to  a  negative  value. 

5.  Change  would  cause  elapsed  time  to  overflow. 

6.  Change  would  cause  epoch  time  to  overflow. 

7.  Network  failure:  A  processor  in  the  network  fails  to  respond  appropriately  to  the 
synchronization  protocol. 

8.  Multiple  synchronization  failure:  A  processor  attempts  to  synchronize  time  while  a 
previous  invocation  of  the  synchronization  protocol  is  in  progress. 
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9.  Synchronization  timeout:  The  synchronization  protocol  does  not  complete  before 
the  timeout  expires. 


CMU/SEI-88-TR-16 


91 


92 


CMU/SEI-88-TR-1 6 


22.  Alarm  Management 

This  chapter  outlines  the  primitives  for  alarm  management.  Alarms  are: 

•  Enforced  changes  in  process  state. 

•  Caused  by  the  expiration  of  a  timeout. 

•  Asynchronous  events  that  are  allocated  on  a  per-process  basis  (each  process  may 
have  no  more  than  one  alarm). 

Processes  view  alarms  as  a  possible  change  in  priority  with  an  enforced  transfer  of  control  to  an 
exception  handler.  Alarms  are  requested  to  expire  at  some  specified  time  in  the  future.  When  an 
alarm  expires,  the  Kernel  raises  the  alarm_explred  exception,  which  the  process  is  expected  to 
handle  as  appropriate.  Note  that  if  a  zero  or  negative  duration  or  an  absolute  time  in  the  past  is 
specified,  the  alarm  expires  immediately.  Alarms  are  intended  for  use  in  the  construction  of 
cyclical  processes  (as  shown  in  the  Kernel  User's  Manual). 


22.1.  Primitives 

22.1.1.  Set  alarm 

This  primitive  defines  an  alarm  that  will  interrupt  the  process  if  it  expires.  An  optional  resumption 
priority  may  be  specified.  If  the  alarm  expires,  the  Kernel  raises  the  alarm_explred  exception 
(when  the  process  is  running),  and  control  passes  to  the  exception  handler  of  the  process.  This 
primitive  may  be  invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  Resetting  existing  alarm 

22.1.2.  Cancel  alarm 

This  primitive  turns  off  an  alarm  that  was  set  but  has  not  yet  expired.  This  primitive  may  be 
invoked  by  any  process  at  any  time. 

This  primitive  can  give  rise  to  the  following  status  codes: 

•  OK 

•  No  alarm  set 


22.2.  Blocking  Primitives 

None. 
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22.3.  Errors 

1.  OK 

2.  Resetting  existing  alarm 

3.  No  alarm  set 
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23.  Tool  Interface 


The  Kernel  is  a  utility  intended  to  support  the  building  of  distributed  Ada  applications.  As  such,  it 
is  important  the  the  Kernel  be  able  to  work  in  harmony  with  user-developed  support  tools.  To 
provide  that  support,  the  Kernel  must  provide  a  window  into  its  internal  workings.  It  is  envisioned 
that  a  tool  is  simply  another  Kernel  process  executing  on  one  or  more  of  the  processors  in  the 
network.  As  such,  the  tool  has  access  to  all  the  Kernel  primitives.  Using  these  primitives  along 
with  the  tool  interface  described  below,  a  number  of  potential  tools  could  be  built,  such  as: 

•  Process  Performance  Monitor:  compiles  statistics  about  the  runtime  performance  of 
a  process(es). 

•  Processor  performance  monitor:  Compiles  processor-level  statistics. 

•  Network  performance  monitor:  Compiles  network-level  statistics. 

•  Interrupt  activity  monitor:  Compiles  statistics  on  the  frequency  of  interrupts  and  the 
amount  of  time  spent  in  various  interrupt  handlers. 

•  Message  performance  monitor:  Compiles  statistics  about  the  frequency  of 
messages,  average  message  length,  peak  bus  usage,  etc. 

Given  the  above  motivation  for  the  tool  interface,  the  actual  form  of  the  interface  is  driven  by  the 
following  concepts: 

•  The  tool  needs  easy  access  to  all  the  information  of  the  Kernel.  Whether  or  not  the 
tool  can  make  use  of  the  information  is  not  the  Kernel’s  concern.  The  key  is  that  the 
Kernel  must  provide  visibility  into  everything  it  knows  intrinsically,  without  expending 
resources  to  combine  that  intrinsic  knowledge  in  any  way. 

•  The  extraction  of  Information  based  on  what  the  Kernel  knows  is  left  to  the  tool  (and 
Indeed,  it  Is  deemed  to  be  the  function  of  a  tool).  It  is  in  the  domain  of  the  tool  where 
the  intrinsic  Kernel  information  is  combined  and  presented  in  some  context-specific 
manner. 

•  The  internal  Kernel  information  must  be  provided  in  a  manner  that  does  not 
compromise  the  integrity  of  the  Kernel;  this  implies  a  read-only  access  to  the 
Kernel's  internal  data  structures. 

•  The  performance  impact  of  using  the  tool  interface  must  be  predictable.  Obviously, 
the  performance  impact  will  not  be  entirely  predictable  given  the  non-determinism 
inherent  in  the  activities  being  monitored.  But  the  tool  interface  bounds  the  impact  in 
a  way  that  gives  insight  into  the  potential  performance  impact  of  a  tool  (of  course,  the 
tool  is  a  process  that  can  be  monitored  like  any  other  process  in  the  system,  so  its 
performance  may  be  determined  empirically).  The  tool  should  consume  predictable 
resources  generally  (not  just  clock  cycles),  e.g.,  storage,  message  bandwidth. 

•  An  application  should  never  have  to  be  modified  simply  to  use  a  tool  (while  this  may 
not  always  be  possible,  it  is  nevertheless  a  desirable  goal).  Therefore,  while  some  of 
the  information  made  available  via  this  interface  could  be  acquired  by  having  the  tool 
communicate  directly  with  an  application  process,  this  approach  is  rejected  as  bad 
tool  design  and  a  distinct  detriment  to  the  application  software  of  an  embedded 
system.  (Note  that  the  Main  Unit  is  used  to  establish  the  process  topology  and  is  not 
considered  application  code.) 

In  general  there  are  two  classes  of  Kernel  information  that  may  be  of  interest  to  a  tool:  process 
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information  and  interrupt  information.  The  primitives  defined  below  describe  the  information 
available  and  the  mechanisms  provided  to  access  this  information. 

23.1.  Primitives 

23.1.1.  Process  information 

The  Kernel  knows  about  all  processes  in  the  system;  therefore,  the  tool  interface  provides  the 
following  information  about  processes  to  the  user: 

•  Process  attributes,  including: 

•  Process  identifier 

•  State  (see  Figure  18-1) 

•  Time  (the  time  when  the  above  state  was  entered) 

•  Priority 

•  Preemption  status 

•  Alarm  status 

•  Primitive  identity 

•  Primitive  return  status  code 

•  Message  attributes,  including: 

•  Sender’s  process  identifier 

•  Receiver’s  process  identifier 

•  Time  the  message  was  sent  or  received 

•  Message  length 

•  Message  tag 

•  Message  contents 

•  Process  table,  which  includes  the  following  information  for  every  declared  process: 

•  Local  process  identifier 

•  Remote  process  identifier 

•  Process  name 

•  Device  name 

•  Local  address 

•  State  (see  Figure  18-1) 

•  Priority 

•  Preemption  status 
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23.1.2.  Interrupt  information 

In  a  manner  analogous  to  process  information,  the  Kernel  knows  all  there  is  to  know  about  the 
interrupts  in  the  system.  Therefore,  the  tool  interface  provides  the  following  interrupt  information 
to  the  user: 

•  Interrupt  activity,  including: 

•  Primitive  identity 

•  Primitive  return  status  code 

•  Interrupt  table,  which  includes  the  following  information  for  every  interrupt: 

•  Interrupt  name 

•  Interrupt  state  (enabled  or  disabled) 

•  Handler  state  (bound,  unbound,  unknown) 

•  Handler  code  address 
« Handler  stack  address 

23.1.3.  Begin  collection 

This  primitive  informs  the  Kernel  of: 

•  What  process  or  message  attribute  to  collect  and  for  which  process  to  collect  it,  or 

•  Which  interrupt  on  which  to  collect  interrupt  attributes. 

The  Kernel  logs  the  data  asynchronously  as  the  state  of  the  process  or  interrupt  changes: 

•  Received  message  bodies  are  logged  as  new  messages  arrive  for  the  process. 

•  Sent  message  bodies  are  logged  as  the  process  sends  messages. 

•  Process  statistics  are  logged  when  the  process  changes  one  of  its  own  attributes  or 
when  the  scheduler  changes  its  process  state. 

•  Message  attributes  (no  bodies)  are  logged  as  new  messages  arrive  and  leave. 

•  Interrupt  attributes  are  logged  as  the  interrupt  handler  uses  Kernel  primitives. 

The  Kernel  logs  data  by  sending  a  message  to  the  process  that  requested  the  collection 
operation;  this  process  is  presumably  a  part  of  the  tool. 

Nonexistent,  aborted,  or  terminated  processes  for  which  information  is  requested  are  ignored. 
Nonexistent  interrupts  for  which  information  is  requested  are  ignored. 

This  primitive  always  succeeds. 

23.1.4.  Cease  collection 

This  primitive  disables  the  collection  of  the  indicated  attribute  on  the  indicated  process  or 
interrupt. 

This  primitive  always  succeeds. 
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23.1.5.  Read  process  table 

This  primitive  reads  the  Kernel’s  process  table. 

This  primitive  always  succeeds. 

23.1.6.  Read  interrupt  table 

This  primitive  reads  the  Kernel’s  interrupt  table. 

This  primitive  always  succeeds. 

23.2.  Blocking  Primitives 

None. 

23.3.  Status  Codes 

None. 
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Appendix  A:  Glossary 

Absolute  (time): 

A  synonym  for  epoch  time. 

Ada:  ANSI/MIL-STD-1815A.  Related  information  can  be  found  in  Section  4.1. 

Alarm: 

A  single  timer  associated  with  a  process  that  may  expire  during  process  execution.  If  it 
does  expire,  a  change  of  process  state  occurs,  and  the  exception  alarm_explred  is  raised. 
Related  information  can  be  found  in  Chapter  13  and  Chapter  22. 

Asynchronous  (event): 

An  event  that  occurs  while  the  affected  process  is  performing  other  work  or  is  waiting  for 
the  event. 

Blocked  (process  state): 

A  process  that  is  (temporarily)  unable  to  run.  All  process  states  are  described  in  Chapter 
18. 

Blocking  (primitive): 

A  Kernel  primitive  that  causes  the  process  state  to  become  blocked.  The  "blocked" 
process  state  is  described  in  Chapter  18.  Each  chapter  in  Part  3  has  a  paragraph 
discussing  blocking  primitives. 

Cyclic  (process): 

A  Kernel  process  with  all  the  following  characteristics:  it  executes  repeatedly;  it  executes 
within  a  user-defined  time  limit;  if  it  overruns  its  execution  time  limit  (i.e.,  its  "frame"),  then 
the  exception  alarm_explred  is  raised. 

DARK: 

Acronym  for  the  SEI  Distributed  Ada  Real-Time  Kernel  Project. 

Dead  (process  state): 

A  process  that  is  unable  to  run  again.  All  process  states  are  described  in  Chapter  18. 
Device: 

A  hardware  entity  that  can  interrupt  a  processor  or  that  can  communicate  over  the  system 
bus. 

Distributed: 

Executing  on  more  than  one  processor  in  support  of  a  single  application. 

Duration: 

The  Ada  type  duration ;  used  to  measure  e/apsed  time.  Related  information  can  be  found  in 
Chapter  21  and  the  Ada  Lanuage  Reference  Manual. 

Elaboration: 

The  process  by  which  declarations  achieve  their  effect  (such  as  creating  an  object) ;  this 
process  occurs  during  program  execution.  This  definition  is  from  the  Ada  Language 
Reference  Manual. 

Elapsed  (time): 

The  number  of  TICKs  since  the  end  of  the  application  initialization  process.  Related 
Information  can  be  found  in  Chapter  21 . 

Epoch  (time): 

The  value  representing  the  moment  at  which  the  processors  began  to  compute  elapsed 
time.  Related  information  can  be  found  in  Chapter  21 . 

Event: 

Something  that  happens  to  a  process  (e.g.,  the  arrival  of  a  message,  the  arrival  of  an 
acknowledgment,  being  killed  by  another  process). 
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Exception: 

An  error  situation  which  may  arise  during  program  execution.  This  definition  is  from  the 
Ada  Language  Reference  Manual. 

FIFO: 

First  in,  first  out. 

Interrupt: 

Suspension  of  a  process  caused  by  an  event  external  to  that  process,  and  performed  in 
such  a  way  that  the  process  can  be  resumed.  (This  external  event  is  also  called  an 
interrupt.) 

Interrupt  handler: 

Code  automatically  invoked  in  response  to  the  occurrence  of  an  interrupt. 

Kernel: 

Basic  system  software  to  provide  facilities  for  a  specific  class  of  applications. 

NCT: 

Network  Configuration  Table. 

Network: 

Series  of  points  (nodes,  devices,  processors)  interconnected  by  communication  channels. 
Package: 

A  group  of  logically  related  entities,  such  as  types,  objects  of  those  types,  and 
subprograms  with  parameters  of  those  types.  It  is  written  as  a  package  declaration  and  a 
package  body.  A  package  declaration  is  just  a  package  specification  followed  by  a 
semi-colon.  A  package  is  one  kind  of  program  unit.  This  definition  is  from  the  Ada 
Language  Reference  Manual. 

Package  body: 

Contains  implementations  of  subprograms  (and  possibly  tasks  as  other  packages  that  have 
been  specified  in  the  package  declaration).  This  definition  is  from  the  Ada  Language 
Reference  Manual. 

Package  Calendar: 

The  Ada  package  Calendar.  Related  information  can  be  found  in  the  Ada  Language 
Reference  Manual. 

Package  specification: 

Has  a  visible  part,  containing  the  declarations  of  all  entities  that  can  be  explicitly  used 
outside  the  package.  It  may  also  have  a  private  part  containing  structural  details  that 
complete  the  specification  of  the  visible  entities,  but  that  are  irrelevant  to  the  user  of  the 
package.  This  definition  is  from  the  Ada  Language  Reference  Manual. 

Postcondition: 

An  assertion  that  must  be  true  after  the  execution  of  a  statement  or  program  component. 
Pragma: 

Conveys  information  to  the  Ada  compiler.  This  definition  is  from  the  Ada  Language 
Reference  Manual. 

Precondition: 

An  assertion  that  must  be  true  before  the  execution  of  a  statement  or  program  component. 
Primitive: 

Basic  Kernel  action  or  datum. 

Process  (Kernel): 

An  object  of  concurrent  execution  managed  by  the  Kernel  outside  the  knowledge  and 
control  of  the  Ada  runtime  environment:  a  schedulable  unit  of  parallel  execution.  Related 
information  can  be  found  in  Chapter  2. 
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Process  stack: 

Built  by  the  Kernel  when  creating  a  Kernel  process.  The  process  stack  contains  a  stack 
plug  (to  prevent  the  propagation  of  unhandled  exceptions),  a  dummy  call  frame  (pointing  to 
process  termination  code),  and  a  place  for  process-local  variables. 

Processor: 

Central  processing  unit  (CPU). 

Real-time: 

"When  it  is  done  is  as  important  as  what  is  done." 

Runtime: 

The  period  of  time  during  which  a  program  is  executing. 

Running  (process  state): 

A  process  that  is  executing  on  its  processor.  All  process  states  are  described  in  Chapter 
18. 

Semaphore: 

A  mechanism  for  controlling  process  synchronization,  often  used  to  implement  a  solution  to 
the  mutual  exclusion  problem.  Related  information  can  be  found  in  Chapters  8  and  17. 

SLICE: 

The  smallest  schedulable  interval  of  time.  The  user  references  time  in  units  of  SLICE. 
Related  information  can  be  found  in  Chapter  21 . 

Status  code: 

Generic  term  used  to  indicate  the  status  of  the  execution  of  a  Kernel  primitive.  A  status 
code  may  correspond  to  an  output  parameter  of  some  discrete  type  or  to  an  exception. 
Related  information  can  be  found  in  Chapter  4.4.  In  addition,  each  chapter  in  Part  3  has  a 
paragraph  discussing  status  codes  for  each  primitive. 

Suspended  (process  state): 

A  process  that  is  able  to  run  but  cannot  because  a  process  of  higher  or  equal  priority  is 
running.  All  process  states  are  described  in  Chapter  18. 

Synchronous  (event): 

An  event  that  happens  while  a  process  is  looking  for  that  event. 

System  bus: 

Communication  medium  connecting  processors  and  devices  into  a  network. 

Task: 

An  Ada  language  construct  that  represents  an  object  of  concurrent  execution  managed  by 
the  Ada  runtime  environment  supplied  as  part  of  a  compiler.  Related  information  can  be 
found  in  Chapter  2  and  the  Ada  Language  Reference  Manual. 

TICK: 

The  smallest  resolvable  interval  of  time.  The  Kernel  references  time  in  units  of  TICK. 
Related  information  can  be  found  in  Chapter  21 . 

Time: 

The  Ada  type  time ;  used  to  measure  epoch  time.  Related  information  can  be  found  in 
Chapter  21  and  the  Ada  Language  Reference  Manual. 


CMU/SEI-88-TR-1 6 


101 


102 


CMU/SEI-88-TR-1 6 


Appendix  B:  Mapping  from  Kernel  Primitives  to 
Requirements 

This  appendix  maps  each  requirement  onto  the  specific  primitive  (represented  by  normal 
facecode)  or  functional  area  (represented  by  italic  facecode)  to  which  it  applies.  It  provides  a 
definition  of  the  functionality  and  performance  required  for  each  primitive  and  functional  area. 
This  mapping  is  the  inverse  of  the  mapping  shown  in  Appendix  C. 


Processor  Management  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Processor  Management 

6.1.6 

6.1.7 

6.1.8 

6.1.9 

6.1.10 

6.1.11 

Initialize  Master 

6.1.1 

6.1.3 

6.1.4 

6.2.1 

Initialize  subordinate 

6.1.2 

6.1.3 

6.1.4 

6.2.1 

Create  network  configuration 

6.1.10 

10.1.6 

10.1.26 

6.2.1 
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Process  Management  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Process  Management 

6.1.9 

7.1.1 

7.1.2 

7.1.13 

Declare  process 

7.1.3 

10.1.1 

10.1.6 

6.2.1 

Create  process 

7.1.4 

7.1.5 

7.1.6 

7.1.7 

7.1.8 

7.1.9 

7.1.10 

7.1.11 

7.1.12 

7.1.25 

7.1.26 

9.1.1 

9.1.2 

9.1.7 

9.1.11 

6.2.1 

7.2.1 

7.2.5 

7.2.6 

Initialization  complete 

7.1.15 

7.1.16 

7.1.17 

7.1.25 

7.1.26 

6.2.1 

Die 

7.1.18 

7.1.25 

7.1.26 

7.2.2 

Kill 

7.1.19 

7.1.20 

7.1.25 

7.1.26 

7.2.3 

Who  am  i 

7.1.23 

Name  of 

7.1.24 

7.1.25 

7.1.26 

10.1.1 

Allocate  device 

7.1.14 

7.2.4 
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Semaphore  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Semaphore  Management 

Create 

8.1.1 

8.1.2 

8.2.1 

Claim 

8.1.3 

8.1.4 

8.1.5 

8.1.6 

8.1.7 

8.1.8 

8.1.9 

9.1.6 

9.1.8 

8.2.2 

Release 

8.1.10 

8.1.11 

8.2.3 
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Schedule  Management  Primitives 

Behavior 

Performance 

Kernel  Primitive 

Requirement 

Requirement 

Schedule  Management 

9.1.3 

9.2.4 

9.1.4 

9.2.6 

9.1.5 

9.1.10 

9.1.21 

9.1.24 

9.2.7 

9.1.26 

9.1.27 

Set  process  preemption 

9.1.12 

9.1.22 

9.2.2 

Get  process  preemption 

9.1.13 

Set  process  priority 

9.1.6 

9.1.8 

9.1.22 

9.2.1 

Get  process  priority 

9.1.9 

Wait 

9.1.6 

9.1.8 

9.1.14 

9.1.15 

9.1.16 

9.1.17 

9.1.22 

11.1.12 

9.2.3 

Set  timeslice 

9.1.18 

Enable  time  slicing 

9.1.19 

9.2.5 

Disable  time  slicing 

9.1.20 

9.2.5 
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Communication  Management  Primitives 

Behavior 

Performance 

Kernel  Primitive 

Requirement 

Requirement 

Communication  Management 

6.1.9 

6.1.11 

7.1.14 

10.1.19 

10.1.22 

10.1.23 

10.1.28 

10.1.29 

10.1.30 

10.1.31 

Send  message 

7.1.21 

10.2.1 

7.1.22 

10.2.2 

10.1.2 

10.2.5 

10.1.5 

10.2.6 

10.1.6 

10.1.25 

10.1.26 

10.2.11 

Send  message  and  wait 

7.1.21 

10.2.3 

7.1.22 

10.2.4 

7.1.25 

10.2.7 

7.1.26 

10.2.8 

9.1.6 

9.1.8 

9.1.22 

10.1.2 

10.1.3 

10.1.4 

10.1.5 

10.1.6 

10.1.7 

10.1.8 

10.1.9 

10.1.10 

10.1.11 

10.1.25 

10.1.27 

11.1.12 

10.2.11 
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Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Receive  message 

9.1.6 

9.1.8 

9.1.22 

10.1.12 

10.1.13 

10.1.14 

10.1.15 

10.1.16 

10.1.17 

10.1.18 

10.1.20 

10.1.21 

10.1.24 

10.1.26 

11.1.12 

10.2.9 

10.2.10 
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interrupt  Management  Primitives 

Behavior 

Performance 

Kernel  Primitive 

Requirement 

Requirement 

Interrupt  Management 

11.1.1 

11.2.1 

11.1.3 

11.2.2 

11.1.6 

11.1.12 

11.1.13 

11.2.4 

Enable 

11.1.4 

Disable 

11.1.5 

Enabled 

11.1.7 

Simulate  interrupt 

11.1.8 

Bind  interrupt  handler 

11.1.2 

11.1.9 

11.1.10 

11.1.11 

11.2.3 
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Time  Management  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Time  Management 

6.1.6 

12.1.2 

12.1.7 

12.1.8 

12.1.9 

12.1.11 

12.1.13 

12.1.14 

12.1.3 

Package  Calendar 

12.1.1 

Time  constants 

12.1.4 

12.1.5 

12.1.6 

Adjust  elapsed  time 

12.1.10 

12.2.1 

Adjust  epoch  time 

12.1.12 

12.2.2 

Read  clock 

12.1.15 

12.2.3 

Synchronize 

12.1.16 

12.1.17 

12.1.18 

12.1.19 

12.1.20 

12.1.21 

12.2.4 

12.2.5 
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Alarm  Management  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Alarm  Management 

13.1.4 

13.1.5 

13.2.3 

Set  alarm 

9.1.6 

9.1.8 

9.1.22 

13.1.1 

13.1.2 

13.1.3 

13.1.5 

13.1.6 

13.1.7 

13.1.8 

13.1.9 

13.2.1 

Cancei  aiarm 

9.1.22 

13.1.10 

13.2.2 
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Tool  Interface  Primitives 

Kernel  Primitive 

Behavior 

Requirement 

Performance 

Requirement 

Tool  Interface 

14.1.2 

14.1.3 

14.1.4 

14.1.5 

14.1.21 

14.2.3 

14.2.4 

14.2.5 

14.2.6 

Process  information 

14.1.6 

14.1.9 

14.1.10 

14.1.12 

14.1.13 

14.1.19 

Interrupt  information 

14.1.15 

14.1.18 

14.1.20 

Begin  collection 

14.1.1 

14.1.6 

14.1.9 

14.1.7 

14.1.10 

14.1.12 

14.1.13 

14.1.15 

14.1.16 

14.1.22 

14.2.1 

Cease  collection 

14.1.8 

14.1.11 

14.1.14 

14.1.17 

14.2.2 

Read  process  table 

14.1.19 

Read  interrupt  table 

14.1.20 
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Appendix  C:  Mapping  from  Requirements  to  Kernel 
Primitives 


This  appendix  maps  each  of  the  specific  primitives  (represented  by  normal  facecode)  or 
functional  area  (represented  by  italic  facecode)  onto  the  requirements  that  it  implements.  It 
provides  a  definition  of  where  specific  functionality  and  performance  requirements  are  met.  This 
mapping  is  the  inverse  of  the  mapping  shown  in  Appendix  B. 


General  Requirements 

Requirement 

Kernel  Primitive 

5.1.1 

all  primitives 

5.1.2 

all  primitives 

5.1.3 

all  primitives 

5.1.4 

all  primitives 

5.1.5 

all  primitives 

5.1.6 

all  primitives 

5.1.7 

all  primitives 

5.1.8 

all  primitives 

5.2.1 

all  primitives 

5.2.2 

all  primitives 

5.2.3 

all  primitives 

5.2.4 

all  primitives 

5.2.5 

all  primitives 
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Processor  Requirements 

Requirement 

Kernel  Primitive 

6.1.1 

Initialize  Master 

6.1.2 

Initialize  subordinate 

6.1.3 

Initialize  Master 

Initialize  subordinate 

6.1.4 

Initialize  Master 

6.1.5 

Initialize  Master 

6.1.6 

Processor  Management 

Time  Management 

6.1.7 

Processor  Management 

6.1.8 

Processor  Management 

6.1.9 

Initialize  Master 

Initialize  subordinate 

Create  process 

Initialization  complete 

Die 

Kill 

Send  message 

Send  message  and  wait 
Receive  message 

6.1.10 

Initialize  Master 

Initialize  subordinate 

Create  network  configuration 

6.1.11 

Processor  Management 
Process  Management 
Interrupt  Management 
Communication  Management 

6.2.1 

Initialize  Master 

Initialize  subordinate 

Declare  process 

Create  process 

Create  network  configuration 
Initialization  complete 
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Process  Requirements 

Requirement 

Kernel  Primitive 

7.1.1 

Process  Management 

7.1.2 

Process  Management 

7.1.3 

Declare  process 

7.1.4 

Create  process 

7.1.5 

Create  process 

7.1.6 

Create  process 

7.1.7 

Create  process 

7.1.8 

Create  process 

7.1.9 

Create  process 

7.1.10 

Create  process 

7.1.11 

Create  process 

7.1.12 

Create  process 

7.1.13 

Process  Management 

7.1.14 

Communication  Management 
Allocate  device 

7.1.15 

Initialization  complete 

7.1.16 

Initialization  complete 

7.1.17 

Initialization  complete 

7.1.18 

Die 

7.1.19 

Kill 

7.1.20 

Kill 

7.1.21 

Send  message 

Send  message  and  wait 

7.1.22 

Send  message 

Send  message  and  wait 

7.1.23 

Who  am  1 

7.1.24 

Name  of 

7.1.25 

Create  process 

Initialization  complete 

Die 

Kill 

Name  of 

Send  message  and  wait 
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Requirement 

Kernel  Primitive 

7.1.26 

Create  process 

Initialization  complete 

Die 

Kill 

Name  of 

Send  message  and  wait 

7.2.1 

Create  process 

7.2.2 

Die 

7.2.3 

Kill 

7.2.4 

Allocate  device 

7.2.5 

Create  process 

7.2.6 

Create  process 
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Semaphore  Requirements 

Requirement 

Kernel  Primitive 

8.1.1 

Create  semaphore 

8.1.2 

Create  semaphore 

8.1.3 

Claim  semaphore 

8.1.4 

Claim  semaphore 

8.1.5 

Claim  semaphore 

8.1.6 

Claim  semaphore 

8.1.7 

Claim  semaphore 

8.1.8 

Claim  semaphore 

8.1.9 

Claim  semaphore 

8.1.10 

Release  semaphore 

8.1.11 

Release  semaphore 

8.2.1 

Create  semaphore 

8.2.2 

Claim  semaphore 

8.2.3 

Release  semaphore 
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Scheduling  Requirments 

Requirement 

Kernel  Primitive 

9.1.1 

Create  process 

9.1.2 

Create  process 

9.1.3 

Schedule  Management 

9.1.4 

Schedule  Management 

9.1.5 

Schedule  Management 

9.1.6 

Set  process  priority 

Wait 

Claim  semaphore 

Send  message  and  wait 
Receive 

Set  alarm 

9.1.7 

Create  process 

9.1.8 

Set  process  priority 

Wait 

Claim  semaphore 

Send  message  and  wait 
Receive 

Set  alarm 

9.1.9 

Get  process  priority 

9.1.10 

Schedule  Management 

9.1.11 

Create  process 

9.1.12 

Set  process  preemption 

9.1.13 

Get  process  preemption 

9.1.14 

Wait 

9.1.15 

Wait 

9.1.16 

Wait 

9.1.17 

Wait 

9.1.18 

Set  time  slice 

9.1.19 

Enable  time  slicing 

9.1.20 

Disable  time  slicing 

9.1.21 

Schedule  Management 

9.1.22 

Set  process  preemption 
Set  process  priority 

Wait 

Claim  semaphore 

Send  message  and  wait 
Receive 

Set  alarm 

Cancel  alarm 
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Requirement 

Kernel  Primitive 

9.1.23 

Schedule  Management 

9.1.24 

Schedule  Management 

9.1.25 

Schedule  Management 

9.1.26 

Schedule  Management 

9.1.27 

Schedule  Management 

9.2.1 

Set  process  priority 

9.2.2 

Set  process  preemption 

9.2.3 

Wait 

9.2.4 

Schedule  Management 

9.2.5 

Enable  time  slicing 
Disable  time  slicing 

9.2.6 

Schedule  Management 

9.2.7 

Schedule  Management 
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Communication  Requirements 

Requirement 

Kernel  Primitive 

10.1.1 

Declare  process 

10.1.2 

Create  process 

Send  message 

Send  message  and  wait 

10.1.3 

Send  message  and  wait 

10.1.4 

Send  message  and  wait 

10.1.5 

Send  message 

Send  message  and  wait 

10.1.6 

Create  network  configuration 
Declare  process 

10.1.7 

Send  message  and  wait 

10.1.8 

Send  message  and  wait 

10.1.9 

Send  message  and  wait 

10.1.10 

Send  message  and  wait 

10.1.11 

Send  message  and  wait 

10.1.12 

Create  process 

Receive  message 

10.1.13 

Receive 

10.1.14 

Receive  message 

10.1.15 

Receive  message 

Create  network  configuration 

10.1.16 

Receive  message 

10.1.17 

Receive  message 

10.1.18 

Receive  message 

10.1.19 

Communication  Management 

10.1.20 

Receive  message 

10.1.21 

Send  message 

Send  message  and  wait 
Receive  message 

10.1.22 

Communication  Management 

10.1.23 

Send  message 

Send  message  and  wait 

10.1.24 

Receive  message 

10.1.25 

Send  message  and  wait 

10.1.26 

Create  network  configuration 
Send  message 

Receive  message 
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Requirement 

Kernel  Primitive 

10.1.27 

Send  message  and  wait 

10.1.28 

Communication  Management 

10.1.29 

Communication  Management 

10.1.30 

Communication  Management 

10.1.31 

Communication  Management 

10.2.1 

Send  message 

10.2.2 

Send  message 

10.2.3 

Send  message  and  wait 

10.2.4 

Send  message  and  wait 

10.2.5 

Send  message 

10.2.6 

Send  message 

10.2.7 

Send  message  and  wait 

10.2.8 

Send  message  and  wait 

10.2.9 

Receive  message 

10.2.10 

Receive  message 

10.2.11 

Communication  Management 
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Interrupt  Requirements 

Requirement 

Kernel  Primitive 

11.1.1 

Interrupt  Management 

11.1.2 

Interrupt  Management 

11.1.3 

Interrupt  Management 

11.1.4 

Enable 

11.1.5 

Disable 

11.1.6 

Interrupt  Management 

11.1.7 

Enabled 

11.1.8 

Simulate  interrupt 

11.1.9 

Bind  interrupt  handler 

11.1.10 

Bind  interrupt  handler 

11.1.11 

Bind  interrupt  handler 

11.1.12 

Interrupt  Management 
Wait 

Claim  semaphore 

Send  message  and  wait 
Receive  message 

11.1.13 

Interrupt  Management 

11.1.14 

Interrupt  Management 

11.1.15 

Interrupt  Management 

11.2.1 

Interrupt  Management 

11.2.2 

Interrupt  Management 

11.2.3 

Bind  interrupt  handler 

1 1 .2.4 

Interrupt  Management 
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Time  Requirements 

Requirement 

Kernel  Primitive 

12.1.1 

Package  calendar 

12.1.2 

Time  Management 

12.1.3 

Time  Management 

12.1.4 

Time  constants 

12.1.5 

Time  constants 

12.1.6 

Time  constants 

12.1.7 

Time  Management 

12.1.8 

Time  Management 

12.1.9 

Time  Management 

12.1.10 

Adjust  elapsed  time 

12.1.11 

77me  Management 

12.1.12 

Adjust  epoch  time 

12.1.13 

77me  Management 

12.1.14 

Time  Management 

12.1.15 

Read  clock 

12.1.16 

Synchronize 

12.1.17 

Synchronize 

12.1.18 

Synchronize 

12.1.19 

Synchronize 

12.1.20 

Synchronize 

12.1.21 

Synchronize 

12.2.1 

Adjust  elapsed  time 

12.2.2 

Adjust  epoch  time 

12.2.3 

Read  clock 

12.2.4 

Synchronize 

12.2.5 

Synchronize 
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Alarm  Requirements 

Requirement 

Kernel  Primitive 

13.1.1 

Set  alarm 

13.1.2 

Set  alarm 

13.1.3 

Set  alarm 

13.1.4 

Alarm  Management 

13.1.5 

Alarm  Management 

13.1.6 

Set  alarm 

13.1.7 

Set  alarm 

13.1.8 

Set  alarm 

13.1.9 

Set  alarm 

13.1.10 

Cancel  alarm 

13.2.1 

Set  alarm 

13.2.2 

Cancel  alarm 

13.2.3 

Alarm  Management 

124 


CMU/SEI-88-TR-1 6 


Tool  interface  Requirements 

Requirement 

Kernel  Primitive 

14.1.1 

Begin  collection 

14.1.2 

Tool  Interface 

14.1.3 

Tool  Interface 

14.1.4 

Tool  Interface 

14.1.5 

Tool  Interface 

14.1.6 

Process  information 
Begin  collection 

14.1.7 

Begin  collection 

14.1.8 

Cease  collection 

14.1.9 

Process  information 

14.1.10 

Process  information 
Begin  collection 

14.1.11 

Cease  collection 

14.1.12 

Process  information 

14.1.13 

Process  information 
Begin  collection 

14.1.14 

Cease  collection 

14.1.15 

Begin  collection 

14.1.16 

Interrupt  information 
Begin  collection 

14.1.17 

Cease  collection 

14.1.18 

Interrupt  information 

14.1.19 

Process  information 
Read  process  table 

14.1.20 

Interrupt  information 
Read  interrupt  table 

14.1.21 

Tool  Interface 

14.1.22 

Begin  collection 

14.2.1 

Begin  collection 

14.2.2 

Cease  collection 

14.2.3 

Tool  Interface 

14.2.4 

Tool  Interface 

14.2.5 

Tool  Interface 

14.2.6 

Tool  Interface 
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